Skip to main content

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