Dear all,
Hi Stephen,

thanks for your comments, please see my responses inline.

Stephen Farrell <stephen.farr...@cs.tcd.ie> 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



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to