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

[Kent Watsen <[e-mail]>]

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?

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