Re: [core] Éric Vyncke's No Objection on draft-ietf-core-yang-cbor-16: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Carsten,

Thank you for your reply, I am afraid that we still disagree about the need to mention the use of "Accept:" header to do some content type negotiation in section 7, but this is of course non-blocking. So, it is really up to the authors.

Regards

-éric


-----Original Message-----
From: Carsten Bormann <[e-mail]>
Date: Monday, 7 March 2022 at 23:44
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail] WG ([e-mail])" <[e-mail]>, Marco Tiloca <[e-mail]>
Subject: Re: [core] Éric Vyncke's No Objection on draft-ietf-core-yang-cbor-16: (with COMMENT)

    Hi Éric,

    a little blast from the past, as we haven’t replied to all the COMMENTs yet:

    > On 2021-07-14, at 12:03, Éric Vyncke via Datatracker <[e-mail]> wrote:
    > 
    > Éric Vyncke has entered the following ballot position for
    > draft-ietf-core-yang-cbor-16: No Objection
    > […]
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > Thank you for the work put into this document.
    > 
    > Special thanks to Marco Tiloca for his shepherd's write-up, which contains a
    > good summary of the WG consensus and the doc reviews.
    > 
    > Please find below 2 non-blocking COMMENT points.
    > 
    > I hope that this helps to improve the document,
    > 
    > Regards,
    > 
    > -éric
    > 
    > == COMMENTS ==
    > 
    > A generic comment about the operational issue of supporting TWO ways to encode
    > a data node: either normal string or the SID. This means that either there is a
    > 2-way negotiation mechanism or that all CORE nodes must support both encoding
    > and have agreed on a common SID mappings. Section 7 only briefly touches this
    > issue with "Content-Type" but not with "Accept".

    Section 7 actually uses the term Content-Type as the combination of a media-type name and optional parameters, as it is used in RFC 9193-to-be (which is waiting for HTTP to be published).
    So I don’t see a need to mention Accept here; readers versed in content-types (media types) should already see the connection.

    > 
    > -- Section 4.2.1 & 4.4.1 --
    > BTW, I like the idea of encoding a container with sequential SID and the delta
    > CBOR encoding ;-)

    Thank you!

    Grüße, Carsten