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

[Carsten Bormann <[e-mail]>]

On 2024-02-02, at 17:49, Kent Watsen <[e-mail]> wrote:
> 
> Hi Carsten,
> 
> I just added "(see Section 4 in <xref target="RFC4648"/>)”
> 
> Here’s the diff:
> 
>           <t>Various examples in this document use "BASE64VALUE=" as a
>             placeholder value for binary data has has been base64
> -            encoded.  This placeholder value is used as real
> -            base64 encoded structures are often many lines long and
> -            hence distracting to the example being presented.</t>
> +            encoded (see Section 4 in <xref target="RFC4648"/>).  This
> +            placeholder value is used as real base64 encoded structures
> +            are often many lines long and hence distracting to the example
> +            being presented.</t>
> 
> Seems okay?

This is not explicitly saying that the reference for doing this is RFC 7950, but I don’t see a lot of danger from this way of putting it.

(please s/used as/used because/ though).

Grüße, Carsten


> 
> Kent
> 
> 
>> On Feb 1, 2024, at 1:26 AM, Carsten Bormann <[e-mail]> wrote:
>> 
>> 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
>>>> 
>>> 
>> 
>