YANG Data Types and Groupings for Cryptography
draft-ietf-netconf-crypto-types-34
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-03-19
|
34 | (System) | RFC Editor state changed to EDIT |
2024-03-19
|
34 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2024-03-19
|
34 | (System) | Announcement was received by RFC Editor |
2024-03-18
|
34 | (System) | IANA Action state changed to In Progress |
2024-03-18
|
34 | Liz Flynn | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2024-03-18
|
34 | Liz Flynn | IESG has approved the document |
2024-03-18
|
34 | Liz Flynn | Closed "Approve" ballot |
2024-03-18
|
34 | Liz Flynn | Ballot approval text was generated |
2024-03-18
|
34 | (System) | Removed all action holders (IESG state changed) |
2024-03-18
|
34 | Robert Wilton | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2024-03-18
|
34 | Robert Wilton | Ballot approval text was generated |
2024-03-16
|
34 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-34.txt |
2024-03-16
|
34 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-03-16
|
34 | Kent Watsen | Uploaded new revision |
2024-03-01
|
33 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-33.txt |
2024-03-01
|
33 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-03-01
|
33 | Kent Watsen | Uploaded new revision |
2024-02-22
|
32 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-32.txt |
2024-02-22
|
32 | (System) | New version approved |
2024-02-22
|
32 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen |
2024-02-22
|
32 | Kent Watsen | Uploaded new revision |
2024-02-08
|
31 | Paul Wouters | [Ballot comment] Thanks for addressing my concerns and questions. I've updated my ballot to Yes |
2024-02-08
|
31 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss |
2024-02-08
|
31 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-31.txt |
2024-02-08
|
31 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-02-08
|
31 | Kent Watsen | Uploaded new revision |
2024-02-08
|
30 | Gyan Mishra | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Gyan Mishra. Sent review to list. |
2024-02-08
|
30 | Roman Danyliw | [Ballot comment] Thank you to Valery Smyslov for the SECDIR review. I support the Paul's DISCUSS position. Thanks for addressing my DISCUSS feedback and most … [Ballot comment] Thank you to Valery Smyslov for the SECDIR review. I support the Paul's DISCUSS position. Thanks for addressing my DISCUSS feedback and most of my COMMENT feedback. ** Section 3.5. When accessing key values, it is desireable that implementations ensure that the strength of the keys being accessed is not greater than the strength of the underlying secure transport connection over which the keys are conveyed. However, comparing key strengths can be complicated and difficult to implement in practice. I don’t understand the guidance in this section. I would have benefited from clarity in the following areas. -- Explain the impact of using keys whose strength exceeds the underlying transport connection (i.e., it doesn’t offer more security) -- The verb “accessing” is confusing. Let’s say that an implementation notices a discrepancy between key strength, what is it supposed to do? -- The last sentence (“However, comparing ...) seems to acknowledge (correctly) that this advice might not be practical. Is the WG sure the text is needed? ** Section 3.6 Implementations SHOULD only use secure transport protocols meeting local policy. A reasonable policy may, e.g., state that only ciphersuites listed as "recommended" by the IETF be used (e.g., [RFC7525] for TLS). -- Would there be instances where implementation would use secure transport that _doesn’t_ meet local policy? -- RFC7525 has been obsoleted. s/RFC7525/RFC9325/ |
2024-02-08
|
30 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2024-02-04
|
30 | (System) | Changed action holders to Robert Wilton (IESG state changed) |
2024-02-04
|
30 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-02-04
|
30 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2024-02-04
|
30 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-30.txt |
2024-02-04
|
30 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-02-04
|
30 | Kent Watsen | Uploaded new revision |
2024-02-01
|
29 | (System) | Changed action holders to Kent Watsen (IESG state changed) |
2024-02-01
|
29 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2024-02-01
|
29 | Lars Eggert | [Ballot comment] # GEN AD review of draft-ietf-netconf-crypto-types-29 CC @larseggert Thanks to Dale R. Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/AmEmW-zWeMAEWMxu8-Czt4ZB_cE … [Ballot comment] # GEN AD review of draft-ietf-netconf-crypto-types-29 CC @larseggert Thanks to Dale R. Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/AmEmW-zWeMAEWMxu8-Czt4ZB_cE). ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 2.1.2, paragraph 1 ``` - The following diagram illustrates the hierarchal relationship amongst + The following diagram illustrates the hierarchical relationship amongst + ++ ``` ### Outdated references Reference `[RFC3447]` to `RFC3447`, which was obsoleted by `RFC8017` (this may be on purpose). Reference `[RFC7525]` to `RFC7525`, which was obsoleted by `RFC9325` (this may be on purpose). Reference `[RFC6125]` to `RFC6125`, which was obsoleted by `RFC9525` (this may be on purpose). ### Grammar/style #### Section 1.1, paragraph 5 ``` placeholder value for binary data has has been base64 encoded. This placeho ^^^^^^^ ``` Possible typo: you repeated a word. #### Section 2.3, paragraph 59 ``` ed-value-format' based identity MUST by set (e.g., cms-encrypted-data-format ^^ ``` Did you maybe mean "buy" or "be"? #### Section 2.3, paragraph 59 ``` ed-value-format' based identity MUST by set (e.g., cms-enveloped-data-format ^^ ``` Did you maybe mean "buy" or "be"? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2024-02-01
|
29 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2024-02-01
|
29 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specification. I have no objection from transport protocol point of view. I was wondering if the following description … [Ballot comment] Thanks for working on this specification. I have no objection from transport protocol point of view. I was wondering if the following description is sufficiently clear to the implementers - leaf public-key-format { nacm:default-deny-write; type identityref { base public-key-format; } mandatory true; description "Identifies the public key's format. Implementations SHOULD ensure that the incoming public key value is encoded in the specified format."; } Which format is specified here ? and how the implementation can ensure the compliance to the specific format for the incoming public key value? I am missing some reference/example/direction here. |
2024-02-01
|
29 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2024-02-01
|
29 | Andrew Alston | [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston |
2024-01-31
|
29 | Murray Kucherawy | [Ballot comment] Similar to what Paul's DISCUSS says: Section 3.5: That said, expert Security opinion suggests that already it is … [Ballot comment] Similar to what Paul's DISCUSS says: Section 3.5: That said, expert Security opinion suggests that already it is infeasible to break a 128-bit symmetric key using a classical computer, and thus the concern for conveying higher-strength keys begins to lose its allure. Can we make a reference to said opinion? Without that, this looks like argument from authority (and an anonymous one at that). === Additional comments from incoming ART AD, Orie Steele: Section 1.4 Prefer to see the exact base64 format cited (not base64url, with or without padding , etc...) ... I assume normative terminology in the model itself, does not contradict the RFCs from which it is derived? > "A private key and, optionally, its associated public key. > Implementations SHOULD ensure that the two keys, when both > are specified, are a matching pair."; Why not MUST? > "A private/public key pair and an associated certificate. > Implementations SHOULD assert that the certificate contains > the matching public key."; Why not MUST? > "A private/public key pair and a list of associated > certificates. Implementations SHOULD assert that > certificates contain the matching public key."; Why not MUST? > 3.3. Unconstrained Public Key Usage This seems not great. later... > whereby associated certificates may constrain the usage of the public key according to local policy. ... > whereby configured certificates (e.g., identity certificates) may constrain the use of the public key according to local policy. Why is this not a SHOULD / MUST ? > 3.5. Strength of Keys Conveyed it might be better to convert this to a recommendation, with MUST NOT / SHOULD NOT, etc... > Implementations SHOULD only use secure transport protocols meeting local policy. Why not MUST ? > This module defines storage for cleartext key values that SHOULD be zeroized when deleted, so as to prevent the remnants of their persisted storage locations from being analyzed in any meaningful way. Nice to see this recommendation. |
2024-01-31
|
29 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2024-01-31
|
29 | Murray Kucherawy | [Ballot comment] Similar to what Paul's DISCUSS says: Section 3.5: That said, expert Security opinion suggests that already it is … [Ballot comment] Similar to what Paul's DISCUSS says: Section 3.5: That said, expert Security opinion suggests that already it is infeasible to break a 128-bit symmetric key using a classical computer, and thus the concern for conveying higher-strength keys begins to lose its allure. Can we make a reference to said opinion? Without that, this looks like argument from authority (and an anonymous one at that). Additional comments from incoming ART AD, Orie Steele: Section 1.4 Prefer to see the exact base64 format cited (not base64url, with or without padding , etc...) ... I assume normative terminology in the model itself, does not contradict the RFCs from which it is derived? > "A private key and, optionally, its associated public key. > Implementations SHOULD ensure that the two keys, when both > are specified, are a matching pair."; Why not MUST? > "A private/public key pair and an associated certificate. > Implementations SHOULD assert that the certificate contains > the matching public key."; Why not MUST? > "A private/public key pair and a list of associated > certificates. Implementations SHOULD assert that > certificates contain the matching public key."; Why not MUST? > 3.3. Unconstrained Public Key Usage This seems not great. later... > whereby associated certificates may constrain the usage of the public key according to local policy. ... > whereby configured certificates (e.g., identity certificates) may constrain the use of the public key according to local policy. Why is this not a SHOULD / MUST ? > 3.5. Strength of Keys Conveyed it might be better to convert this to a recommendation, with MUST NOT / SHOULD NOT, etc... > Implementations SHOULD only use secure transport protocols meeting local policy. Why not MUST ? > This module defines storage for cleartext key values that SHOULD be zeroized when deleted, so as to prevent the remnants of their persisted storage locations from being analyzed in any meaningful way. Nice to see this recommendation. |
2024-01-31
|
29 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2024-01-31
|
29 | Murray Kucherawy | [Ballot comment] Similar to what Paul's DISCUSS says: Section 3.5: That said, expert Security opinion suggests that already it is … [Ballot comment] Similar to what Paul's DISCUSS says: Section 3.5: That said, expert Security opinion suggests that already it is infeasible to break a 128-bit symmetric key using a classical computer, and thus the concern for conveying higher-strength keys begins to lose its allure. Can we make a reference to said opinion? Without that, this looks like argument from authority (and an anonymous one at that). |
2024-01-31
|
29 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2024-01-31
|
29 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2024-01-31
|
29 | Paul Wouters | [Ballot discuss] Thanks to Valery and Rifaat for their secdir reviews. I have some items I would like some clarifications on and some non-blocking comments. … [Ballot discuss] Thanks to Valery and Rifaat for their secdir reviews. I have some items I would like some clarifications on and some non-blocking comments. 2.1.4.12 contains: +-- certificates | +-- certificate* [name] | +-- name? string Certificate identity is either done by entire DN, The Common Name (CN) RDN, or by a list of subjectAltName (SAN) entries. Can the latter be expressed here? Should a type be introduced? ("CN", "DN", "SAN") ? Should the type be a list as 1 certificate can have multiple identities via multiple SAN entries. 2.2.1 talks about "asymmetric key" without specifying if it is referring to a public key or a private key. I think "private" is mean here on all occasions. Should that be clarified? 2.2.1.2 uses "cleartext-key" and "cleartext-private-key". Would it not be less confusing to rename "cleartext-key" to "cleartext-sym-key" ? Section 3.5 That said, expert Security opinion suggests that already it is infeasible to break a 128-bit symmetric key using a classical computer, and thus the concern for conveying higher-strength keys begins to lose its allure. I don't think this document should make this statement. Section 3.6 Use of Recommended Ciphersuites Why is this document containing this single recommendation ? I would rename this section to "Use of Secure Transport Protocols" and refer to RFC 9325 or BCP195 and maybe mention using IKEv2/IPsec RFC 7296 with RFC 8247/8221 as another secure transport that can be used. (I think IKEv2/IPsec might not be used with netconf/restconf so perhaps ignore that part) Section 3.8 states: Passwords and keys may be encrypted via a symmetric key Doesn't this move the problem? Isn't _that_ symmetric key then not still stored in the clear? |
2024-01-31
|
29 | Paul Wouters | [Ballot comment] I see no mention of CRLs or OCSP? Is this not commonly used with NETCONF or RESTCONF ? 2.1.2 What about OpenPGP key … [Ballot comment] I see no mention of CRLs or OCSP? Is this not commonly used with NETCONF or RESTCONF ? 2.1.2 What about OpenPGP key types? Would it be expected some openpgp module would update this module with a new type? 2.1.4 Why not a pkix based grouping for all pkix operations? 2.1.4.2 What about hashed passwords (eg crypt(), PBKDF2, ARGON2, SCRYPT)) and their parameters? I guess passwords here focus on the devices and their storage? not on password types received from a human or the network for validation? Which I would assume is the same reason we do not list PINs anywhere in the model? Section 3.8 states: In order to thwart rainbow attacks, algorithms that result in a unique output for the same input SHOULD NOT be used. For instance, AES using "ECB" SHOULD NOT be used to encrypt values, whereas "CBC" mode is permissible since an unpredictable initialization vector (IV) MUST be used for each use. I didn't find this clear. How about something like: To securely encrypt a password or key with a symmetric key, a proper block cipher mode such as an AEAD or CBC MUST be used. This ensures that a random IV is part of the input, which guarantees that the output for encrypting the same password or key still produces a different unpredictable ciphertext. This avoids leaking that some encrypted keys or passwords are the same and makes it much harder to pre-generate rainbow tables to brute force attack weak passwords. The ECB block cipher mode MUST NOT be used. However, comparing key strengths can be complicated Add "of different algorithms" ? Because comparing AES128 to AES256 is not complicated :) |
2024-01-31
|
29 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2024-01-31
|
29 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2024-01-31
|
29 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2024-01-31
|
29 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Section 1.4: > value for binary data has has been base64 encoded. This placeholder The … [Ballot comment] Thank you for the work on this document. Section 1.4: > value for binary data has has been base64 encoded. This placeholder The document is missing a reference to RFC 4648 (and specify which encoding, Section 4 or 5). I assume that this is the same as for RFC 7950 which states: Binary values are encoded with the base64 encoding scheme (see Section 4 in [RFC4648]). Even if this is meant to use and extend 7950 (as specified later in 2.1.3), it would be good to repeat the above and reference 4648 early on, rather than relying on the reader investigating capabilities. If you don't want to do it in Section 1.4, I suggest the reference to 4648 and explicitly stating the base64 encoding should be at least added to 2.1.3. RFC 3447 has been obsoleted by 8017. I assume this is an error, given that the doc uses "PKCS #1: RSA Cryptography Specifications Version 2.2" which is actually 8017, rather than version 2.1. |
2024-01-31
|
29 | Francesca Palombini | Ballot comment text updated for Francesca Palombini |
2024-01-31
|
29 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Section 1.4: > value for binary data has has been base64 encoded. This placeholder The … [Ballot comment] Thank you for the work on this document. Section 1.4: > value for binary data has has been base64 encoded. This placeholder The document is missing a reference to RFC 4648 (and specify which encoding, Section 4 or 5). I assume that this is the same as for RFC 7950 which states: Binary values are encoded with the base64 encoding scheme (see Section 4 in [RFC4648]). Even if this is meant to use and extend 7950 (as specified later in 2.1.3), it would be good to repeat the above and reference 4648 early on, rather than relying on the reader investigating capabilities. If you don't want to do it in Section 1.4, I suggest the reference to 4648 and explicitly stating the base64 encoding should be at least added to 2.1.3. |
2024-01-31
|
29 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2024-01-30
|
29 | Warren Kumari | [Ballot comment] I couldn't really decide between No Objection and Discuss. I ended up deciding on No Obj. I'm **assuming** that the "hidden" is conceptually … [Ballot comment] I couldn't really decide between No Objection and Discuss. I ended up deciding on No Obj. I'm **assuming** that the "hidden" is conceptually similar to a write-only variable (or like some device vendors who elide the password/keys/similar in their equivalent of 'show config'), but it's really really unclear -- this section could do with some more words to explain this... |
2024-01-30
|
29 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2024-01-29
|
29 | Roman Danyliw | [Ballot discuss] ** hidden key -- Section 2.1.4.3. “The "hidden-key" node is of type "empty" as the real value cannot be … [Ballot discuss] ** hidden key -- Section 2.1.4.3. “The "hidden-key" node is of type "empty" as the real value cannot be presented via the management interface. ” -- YANG. "A hidden key. How such keys are created is outside the scope of this module."; “hidden key” is underspecified. The above are the two descriptions I found. Could a detailed explanation please be added – what is it? When (how) would one use it? What is the difference between hidden and access controlled? I observe that draft-ietf-netconf-keystore suggests that it could be related to TPMs and Section 4 of that draft uses it in the context of administrators with different privileges. However, this document is the base reference. |
2024-01-29
|
29 | Roman Danyliw | [Ballot comment] Thank you to Valery Smyslov for the SECDIR review. ** Section 2.1.4.8. Editorial. * The "cert-data" node contains a chain of one … [Ballot comment] Thank you to Valery Smyslov for the SECDIR review. ** Section 2.1.4.8. Editorial. * The "cert-data" node contains a chain of one or more certificates encoded using a "signed-data-cms" typedef discussed in Section 2.1.3. I observe that Section 2.1.3 says almost nothing about signed-data-cms ** Section 2.1.4.12. Editorial. The narrative text doesn’t explain what “certificates” are. ** Section 3.5. When accessing key values, it is desireable that implementations ensure that the strength of the keys being accessed is not greater than the strength of the underlying secure transport connection over which the keys are conveyed. However, comparing key strengths can be complicated and difficult to implement in practice. I don’t understand the guidance in this section. I would have benefited from clarity in the following areas. -- Explain the impact of using keys whose strength exceeds the underlying transport connection (i.e., it doesn’t offer more security) -- The verb “accessing” is confusing. Let’s say that an implementation notices a discrepancy between key strength, what is it supposed to do? -- The last sentence (“However, comparing ...) seems to acknowledge (correctly) that this advice might not be practical. Is the WG sure the text is needed? ** Section 3.5. That said, expert Security opinion suggests that already it is infeasible to break a 128-bit symmetric key using a classical computer, and thus the concern for conveying higher-strength keys begins to lose its allure. Recommend removing this generic statement. There would be a variety of reasons operators might choose to use symmetric keys in excess of 128-bits, policy being one of them. ** Section 3.6 Implementations SHOULD only use secure transport protocols meeting local policy. A reasonable policy may, e.g., state that only ciphersuites listed as "recommended" by the IETF be used (e.g., [RFC7525] for TLS). -- Would there be instances where implementation would use secure transport that _doesn’t_ meet local policy? -- RFC7525 has been obsoleted. s/RFC7525/RFC9325/ |
2024-01-29
|
29 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2024-01-29
|
29 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-01-29
|
29 | Éric Vyncke | [Ballot comment] Thanks for the work done. The shepherd's writeup would benefit from a better justification of the intended status. Is there a reason why … [Ballot comment] Thanks for the work done. The shepherd's writeup would benefit from a better justification of the intended status. Is there a reason why there are several NETCONF WG crypto-related I-Ds rather than a single one ? I was about to DISCUSS the following point but balloting ABSTAIN as I am unsure about the use case: the model has cleartext and encrypted passwords (the latter is a hint that the password can be decrypted back to cleartext) but what about password hashes if the remote party should also be authenticated over a protected channel by sending a clear text password ? Another near-DISCUSS point: what about key rollover when 2 keys/passwords could be used ? As in another document, it is nice to have a certificate expiration date but what about a 'not valid before' date ? This is similar to the previous point of key rollover. Please add a reference to `rainbow attacks`. |
2024-01-29
|
29 | Éric Vyncke | [Ballot Position Update] New position, Abstain, has been recorded for Éric Vyncke |
2024-01-28
|
29 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2024-01-26
|
29 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2024-01-26
|
29 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-29.txt |
2024-01-26
|
29 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2024-01-26
|
29 | Kent Watsen | Uploaded new revision |
2024-01-26
|
29 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2024-01-25
|
28 | Robert Wilton | Placed on agenda for telechat - 2024-02-01 |
2024-01-25
|
28 | Robert Wilton | Ballot has been issued |
2024-01-25
|
28 | Robert Wilton | [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton |
2024-01-25
|
28 | Robert Wilton | Created "Approve" ballot |
2024-01-25
|
28 | Robert Wilton | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-01-25
|
28 | Robert Wilton | Ballot writeup was changed |
2024-01-25
|
28 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-01-22
|
28 | Dale Worley | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. |
2024-01-17
|
28 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2024-01-17
|
28 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-netconf-crypto-types-28. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-netconf-crypto-types-28. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there are two actions which we must complete. First, in the ns registry in the IETF XML Registry group located at: https://www.iana.org/assignments/xml-registry/ a single new namespace will be registered as follows: ID: yang:ietf-crypto-types URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request. Second, in the YANG Module Names registry in the YANG Parameters registry group located at: https://www.iana.org/assignments/yang-parameters/ a single new YANG module will be registered as follows: Name: ietf-crypto-types File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types Prefix: ct Module: Reference: [ RFC-to-be ] While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published. We understand that these are the only actions required to be completed upon approval of this document. NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-01-11
|
28 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Gyan Mishra |
2024-01-11
|
28 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2024-01-11
|
28 | David Dong | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-01-10
|
28 | David Dong | IANA Experts State changed to Reviews assigned |
2024-01-10
|
28 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2024-01-10
|
28 | Cindy Morgan | The following Last Call announcement was sent out (ends 2024-01-24): From: The IESG To: IETF-Announce CC: draft-ietf-netconf-crypto-types@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org, rwilton@cisco.com … The following Last Call announcement was sent out (ends 2024-01-24): From: The IESG To: IETF-Announce CC: draft-ietf-netconf-crypto-types@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org, rwilton@cisco.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (YANG Data Types and Groupings for Cryptography) to Proposed Standard The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'YANG Data Types and Groupings for Cryptography' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2024-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7093: Additional Methods for Generating Key Identifiers Values (Informational - Independent Submission) |
2024-01-10
|
28 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2024-01-10
|
28 | Robert Wilton | Last call was requested |
2024-01-10
|
28 | Robert Wilton | Ballot approval text was generated |
2024-01-10
|
28 | Robert Wilton | Ballot writeup was generated |
2024-01-10
|
28 | Robert Wilton | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2024-01-10
|
28 | Robert Wilton | Last call announcement was generated |
2023-12-28
|
28 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-28.txt |
2023-12-28
|
28 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2023-12-28
|
28 | Kent Watsen | Uploaded new revision |
2023-04-17
|
27 | (System) | Changed action holders to Robert Wilton (IESG state changed) |
2023-04-17
|
27 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-04-17
|
27 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-27.txt |
2023-04-17
|
27 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2023-04-17
|
27 | Kent Watsen | Uploaded new revision |
2023-03-22
|
26 | (System) | Changed action holders to Kent Watsen, Robert Wilton (IESG state changed) |
2023-03-22
|
26 | Robert Wilton | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2022-12-19
|
26 | (System) | Changed action holders to Robert Wilton (IESG state changed) |
2022-12-19
|
26 | Robert Wilton | IESG state changed to AD Evaluation from Publication Requested |
2022-12-12
|
26 | Mahesh Jethanandani | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The WG consensus represents the views of a several individuals who commented on this and related documents. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? This particular draft did not have any controversies or had decisions that were particularly rough. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Nobody has threatened an appeal or otherwise indicated extreme discontent. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? This document defines YANG groupings for other modules and drafts to use. Any implementation of the module would result from those modules and drafts being implemented. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. The contents of this document interact with other WG, e.g. TLS, that was informed of the draft and had an opportunity to comment on the draft. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This document was reviewed both by YANG Doctor and underwent a SecDir review. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? The document contains one YANG module that has been validated with both pyang and yanglint, and resulted in no errors being reported. The module does comply with NMDA, and states it as much in the document. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. The document contains examples that can be used to validate the YANG module. A check of those examples using yanglint resulted in all the checks passing. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? This document has undergone multiple reviews from different reviewers and it is the shepherd's belief that the document is ready to be handed to AD for their review. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? In the OPS area, the use of MIB and YANG modules was identified for common issues, and addressed. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? This document is requesting a Proposed Standard stream, and states so in the document. The document defines a YANG module and as such Proposed Standard is the proper type. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. An IPR declaration was solicited as part of moving the document to LC, and all the authors and contributors acknowledged that there were not aware of any IPR. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. There is only one author of the document. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) Yes, a idnits run did indicate some errors, and while most of them were bogus, there is one issue that the author needs to address. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. The informative and normative references have been correctly classified. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? All the normative references are freely available to anyone. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. idnits refers to the following normative references as downward reference: ** Downref: Normative reference to an Informational RFC: RFC 7093 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No. There are no normative references to documents that are not ready to be submitted or in unclear state. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. The publication of this document does not not change the status of any existing RFC. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The document does not create any new IANA registries. It adds to two existing registries/sub-registries. Those two registries/sub-registries have been clearly identified. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. There are no new IANA registries defined in this document. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2022-12-12
|
26 | Mahesh Jethanandani | Responsible AD changed to Robert Wilton |
2022-12-12
|
26 | Mahesh Jethanandani | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2022-12-12
|
26 | Mahesh Jethanandani | IESG state changed to Publication Requested from I-D Exists |
2022-12-12
|
26 | Mahesh Jethanandani | Document is now in IESG state Publication Requested |
2022-12-12
|
26 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-26.txt |
2022-12-12
|
26 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2022-12-12
|
26 | Kent Watsen | Uploaded new revision |
2022-11-12
|
25 | Mahesh Jethanandani | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The WG consensus represents the views of a several individuals who commented on this and related documents. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? This particular draft did not have any controversies or had decisions that were particularly rough. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Nobody has threatened an appeal or otherwise indicated extreme discontent. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? This document defines YANG groupings for other modules and drafts to use. Any implementation of the module would result from those modules and drafts being implemented. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. The contents of this document interact with other WG, e.g. TLS, that was informed of the draft and had an opportunity to comment on the draft. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This document was reviewed both by YANG Doctor and underwent a SecDir review. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? The document contains one YANG module that has been validated with both pyang and yanglint, and resulted in no errors being reported. The module does comply with NMDA, and states it as much in the document. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. The document contains examples that can be used to validate the YANG module. A check of those examples using yanglint resulted in all the checks passing. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? This document has undergone multiple reviews from different reviewers and it is the shepherd's belief that the document is ready to be handed to AD for their review. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? In the OPS area, the use of MIB and YANG modules was identified for common issues, and addressed. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? This document is requesting a Proposed Standard stream, and states so in the document. The document defines a YANG module and as such Proposed Standard is the proper type. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. An IPR declaration was solicited as part of moving the document to LC, and all the authors and contributors acknowledged that there were not aware of any IPR. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. There is only one author of the document. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) Yes, a idnits run did indicate some errors, and while most of them were bogus, there is one issue that the author needs to address. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. The informative and normative references have been correctly classified. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? All the normative references are freely available to anyone. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. idnits refers to the following normative references as downward reference: ** Downref: Normative reference to an Informational RFC: RFC 7093 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No. There are no normative references to documents that are not ready to be submitted or in unclear state. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. The publication of this document does not not change the status of any existing RFC. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The document does not create any new IANA registries. It adds to two existing registries/sub-registries. Those two registries/sub-registries have been clearly identified. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. There are no new IANA registries defined in this document. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2022-10-19
|
25 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-25.txt |
2022-10-19
|
25 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2022-10-19
|
25 | Kent Watsen | Uploaded new revision |
2022-08-30
|
24 | Mahesh Jethanandani | Notification list changed to mjethanandani@gmail.com because the document shepherd was set |
2022-08-30
|
24 | Mahesh Jethanandani | Document shepherd changed to Mahesh Jethanandani |
2022-07-18
|
24 | Kent Watsen | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2022-07-18
|
24 | Kent Watsen | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2022-07-07
|
24 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-24.txt |
2022-07-07
|
24 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2022-07-07
|
24 | Kent Watsen | Uploaded new revision |
2022-05-24
|
23 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-23.txt |
2022-05-24
|
23 | Kent Watsen | New version accepted (logged-in submitter: Kent Watsen) |
2022-05-24
|
23 | Kent Watsen | Uploaded new revision |
2022-03-07
|
22 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-22.txt |
2022-03-07
|
22 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2022-03-07
|
22 | Kent Watsen | Uploaded new revision |
2021-12-17
|
21 | Kent Watsen | Changed consensus to Yes from Unknown |
2021-12-17
|
21 | Kent Watsen | Intended Status changed to Proposed Standard from None |
2021-09-14
|
21 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-21.txt |
2021-09-14
|
21 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2021-09-14
|
21 | Kent Watsen | Uploaded new revision |
2021-08-24
|
20 | Valery Smyslov | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Valery Smyslov. Sent review to list. |
2021-07-26
|
20 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Valery Smyslov |
2021-07-26
|
20 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Valery Smyslov |
2021-07-26
|
20 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Leif Johansson was withdrawn |
2021-05-18
|
20 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-20.txt |
2021-05-18
|
20 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2021-05-18
|
20 | Kent Watsen | Uploaded new revision |
2021-02-10
|
19 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-19.txt |
2021-02-10
|
19 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2021-02-10
|
19 | Kent Watsen | Uploaded new revision |
2021-01-12
|
18 | Jürgen Schönwälder | Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Jürgen Schönwälder. Sent review to list. |
2020-12-03
|
18 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Withdrawn': Duplicate review request |
2020-12-03
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Leif Johansson |
2020-12-03
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Leif Johansson |
2020-11-30
|
18 | Mahesh Jethanandani | Requested Last Call review by SECDIR |
2020-11-30
|
18 | Mahesh Jethanandani | Requested Last Call review by SECDIR |
2020-08-20
|
18 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-18.txt |
2020-08-20
|
18 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2020-08-20
|
18 | Kent Watsen | Uploaded new revision |
2020-07-20
|
17 | Kent Watsen | Added to session: IETF-108: netconf Tue-1100 |
2020-07-16
|
17 | Mehmet Ersue | Assignment of request for Last Call review by YANGDOCTORS to Acee Lindem was rejected |
2020-07-15
|
17 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Jürgen Schönwälder |
2020-07-15
|
17 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Jürgen Schönwälder |
2020-07-10
|
17 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-17.txt |
2020-07-10
|
17 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2020-07-10
|
17 | Kent Watsen | Uploaded new revision |
2020-07-10
|
16 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Acee Lindem |
2020-07-10
|
16 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Acee Lindem |
2020-07-09
|
16 | Mahesh Jethanandani | Requested Last Call review by YANGDOCTORS |
2020-07-08
|
16 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-16.txt |
2020-07-08
|
16 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2020-07-08
|
16 | Kent Watsen | Uploaded new revision |
2020-07-06
|
15 | Mahesh Jethanandani | Tag Revised I-D Needed - Issue raised by WGLC set. |
2020-07-06
|
15 | Mahesh Jethanandani | IETF WG state changed to In WG Last Call from WG Document |
2020-05-20
|
15 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-15.txt |
2020-05-20
|
15 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2020-05-20
|
15 | Kent Watsen | Uploaded new revision |
2020-03-08
|
14 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-14.txt |
2020-03-08
|
14 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2020-03-08
|
14 | Kent Watsen | Uploaded new revision |
2019-11-20
|
13 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-13.txt |
2019-11-20
|
13 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2019-11-20
|
13 | Kent Watsen | Uploaded new revision |
2019-11-02
|
12 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-12.txt |
2019-11-02
|
12 | (System) | New version accepted (logged-in submitter: Kent Watsen) |
2019-11-02
|
12 | Kent Watsen | Uploaded new revision |
2019-10-18
|
11 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-11.txt |
2019-10-18
|
11 | (System) | New version approved |
2019-10-18
|
11 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen |
2019-10-18
|
11 | Kent Watsen | Uploaded new revision |
2019-07-22
|
10 | Rifaat Shekh-Yusef | Request for Early review by SECDIR Partially Completed: Not Ready. Reviewer: Rifaat Shekh-Yusef. Sent review to list. |
2019-07-15
|
10 | Tero Kivinen | Request for Early review by SECDIR is assigned to Rifaat Shekh-Yusef |
2019-07-15
|
10 | Tero Kivinen | Request for Early review by SECDIR is assigned to Rifaat Shekh-Yusef |
2019-07-09
|
10 | Mahesh Jethanandani | Requested Early review by SECDIR |
2019-07-02
|
10 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-10.txt |
2019-07-02
|
10 | (System) | New version approved |
2019-07-02
|
10 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen |
2019-07-02
|
10 | Kent Watsen | Uploaded new revision |
2019-07-02
|
10 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen |
2019-07-02
|
10 | Kent Watsen | Uploaded new revision |
2019-06-20
|
09 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-09.txt |
2019-06-20
|
09 | (System) | New version approved |
2019-06-20
|
09 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen |
2019-06-20
|
09 | Kent Watsen | Uploaded new revision |
2019-06-17
|
08 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-08.txt |
2019-06-17
|
08 | (System) | New version approved |
2019-06-17
|
08 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen |
2019-06-17
|
08 | Kent Watsen | Uploaded new revision |
2019-06-07
|
07 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-07.txt |
2019-06-07
|
07 | (System) | New version approved |
2019-06-07
|
07 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen |
2019-06-07
|
07 | Kent Watsen | Uploaded new revision |
2019-04-29
|
06 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-06.txt |
2019-04-29
|
06 | (System) | New version approved |
2019-04-29
|
06 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen |
2019-04-29
|
06 | Kent Watsen | Uploaded new revision |
2019-03-09
|
05 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-05.txt |
2019-03-09
|
05 | (System) | New version approved |
2019-03-09
|
05 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen |
2019-03-09
|
05 | Kent Watsen | Uploaded new revision |
2019-03-09
|
04 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-04.txt |
2019-03-09
|
04 | (System) | New version approved |
2019-03-09
|
04 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen |
2019-03-09
|
04 | Kent Watsen | Uploaded new revision |
2019-03-09
|
03 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-03.txt |
2019-03-09
|
03 | (System) | New version approved |
2019-03-09
|
03 | (System) | Request for posting confirmation emailed to previous authors: HAIGUANG Wang , Kent Watsen , netconf-chairs@ietf.org |
2019-03-09
|
03 | Kent Watsen | Uploaded new revision |
2018-10-22
|
02 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-02.txt |
2018-10-22
|
02 | (System) | New version approved |
2018-10-22
|
02 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , netconf-chairs@ietf.org |
2018-10-22
|
02 | Kent Watsen | Uploaded new revision |
2018-10-22
|
02 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen , netconf-chairs@ietf.org |
2018-10-22
|
02 | Kent Watsen | Uploaded new revision |
2018-09-20
|
01 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-01.txt |
2018-09-20
|
01 | (System) | New version approved |
2018-09-20
|
01 | (System) | Request for posting confirmation emailed to previous authors: Kent Watsen |
2018-09-20
|
01 | Kent Watsen | Uploaded new revision |
2018-08-27
|
00 | Kent Watsen | This document now replaces draft-kwatsen-netconf-crypto-types instead of None |
2018-06-04
|
00 | Kent Watsen | New version available: draft-ietf-netconf-crypto-types-00.txt |
2018-06-04
|
00 | (System) | WG -00 approved |
2018-06-04
|
00 | Kent Watsen | Set submitter to "Kent Watsen ", replaces to (none) and sent approval email to group chairs: netconf-chairs@ietf.org |
2018-06-04
|
00 | Kent Watsen | Uploaded new revision |