Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)

[Benoit Claise <[e-mail]>]

Dear all,
> Hi Stephen,
>
> thanks for your comments, please see my responses inline.
>
> Stephen Farrell <[e-mail]> writes:
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> - I would have thought that it'd be useful to point out any
>> issues with round-tripping, e.g. going from XML to JSON and
>> back to XML or vice-versa. But I didn't see any mention of
>> that. How come?
> I believe fifth paragraph in sec. 3 is what you are asking for:
>
>     With the exception of anyxml and schema-less anydata nodes, it is
>     possible to map a JSON-encoded data tree to XML encoding as defined
>     in [I-D.ietf-netmod-rfc6020bis], and vice versa.  However, such
>     conversions require the YANG data model to be available.
Thanks.
>> - I'm not sure if anyone has considered XMLDSIG or use of JOSE
>> with YANG. If one did, then this kind of mapping would not
>> allow one to preserve digital signatures without a lot of
>> work. I assume that that's considered ok. (Which it can be,
>> depending on how one does object level security, if one does
>> object level security.)
> I am not an expert on digital signatures and their representations, but
> I'd say they could be modelled as YANG's "binary" type (and transferred
> base64-encoded). This should work equally well in XML and JSON,
> including round trips.
I skipped this point above for now as the thread goes on.
>
>> - It's not clear to me if the discussion of the secdir review
>> [1] concluded. It seemed to just stall. Is there more to be
>> said? (If so, be great if the shepherd would kick that
>> discussion.)
> I don't have much more to say without seeing alternative proposals.
I re-reviewed the security directory review, and from my vantage point, 
I believe that Lada addressed the review.

Regards, Benoit
>
> Lada
>
>>     [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06408.html
>>
>>