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

[Kent Watsen <[e-mail]>]

Hi Carsten,

> On Feb 2, 2024, at 11:54 AM, Carsten Bormann <[e-mail]> wrote:
> 
> 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.

Good point.  
How about a xref to https://datatracker.ietf.org/doc/html/rfc7950#section-9.8?
This way folks can quickly see that its using Section 4 in RFC 4648...


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

Fixed - thanks!



This is the total section now:

    Various examples in this document use "BASE64VALUE=" as a placeholder
    value for binary data that has been base64 encoded (per Section 9.8
    of [RFC7950]).  This placeholder value is used because real base64
    encoded structures are often many lines long and hence distracting to
    the example being presented.

Good?


> Grüße, Carsten

Kent


> 
> 
>> 
>> 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
>>>>> 
>>>> 
>>> 
>> 
>