Re: [netconf] Francesca Palombini's No Objection on draft-ietf-netconf-crypto-types-29: (with COMMENT)

[Francesca Palombini <[e-mail]>]

I get not wanting to add it to 1.4, as I said later:

 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.

I also get the point of this only uses whatever 7950 defines, and if that one is updated this will “inherit” the update, but to me this only obfuscates the actual encoding used. A sentence can be added to this document to make it clear and still allow for future updates.

Francesca

From: Carsten Bormann <[e-mail]>
Date: Wednesday, 31 January 2024 at 14:17
To: Francesca Palombini <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [netconf] Francesca Palombini's No Objection on draft-ietf-netconf-crypto-types-29: (with COMMENT)
On 2024-01-31, at 14:04, Francesca Palombini via Datatracker <[e-mail]> wrote:
>
> 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]).

I actually would not add a restatement here.  Section 1.4 only explains the substitution of longer base64 encoded values in the examples by BASE64VALUE= (encoding for the meaningless 8 bytes “04 04 84 eb 85 40 2d 41” hex).

The document uses base64 within YANG-XML and YANG-JSON examples only, and both RFC 7950 and (uncharacteristically for JSON) RFC 7951 use Section 4 of RFC 4648.  This should not be restated — maybe this will be fixed to be base64url in a future version of RFC 7951?
(RFC 9254 (YANG-CBOR) doesn’t use base64 at all for its representation of YANG “binary”, but then the crypto-types document doesn’t have YANG-CBOR examples.)

Grüße, Carsten