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

[Carsten Bormann <[e-mail]>]

Hi Kent,

I haven’t seen your changes yet.
As long as the restatements are clearly marked as such [1], i.e., they don’t appear to make new normative requirements on their own, there is no damage.

[1]: https://www.ietf.org/archive/id/draft-bormann-restatement-00.html#name-defusing-restatements

Grüße, Carsten


> On Feb 1, 2024, at 01:06, Kent Watsen <[e-mail]> wrote:
> 
> Hi Carsten,
> 
> Whoops, just seeing your comment after making the change.
> I agree that it seemed not needed, but I also didn’t see any harm in adding it.
> Thoughts?
> 
> Kent
> 
> 
>> On Jan 31, 2024, at 8:16 AM, Carsten Bormann <[e-mail]> wrote:
>> 
>> 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
>> 
>