Re: [netconf] I-D Action: draft-ietf-netconf-transaction-id-02.txt

["Per Andersson (perander)" <[e-mail]>]

Hi Jan, WG!

Thank you for a thorough and well written document.
See my comments below.


>From Section 4. Txid Mechanisms

   If a client uses more than one txid mechanism, such as both etag and
   last-modified in a particular message to a server, or patricular
   commit, the result is undefined.

Wouldn't it better to define or discuss this to some extent instead of
leaving it as undefined behavior? There are situations which are in
the scope of this document to define.

E.g., what happens if a change is reverted on the server, so the etag is
different, but the last-modified is in the past from previous change?


>From Section 4.1.  The etag attribute txid mechanism

   The etag attribute values are opaque UTF-8 strings chosen freely,
   except that the etag string must not contain space, backslash or
   double quotes.  The point of this restriction is to make it easy to
   reuse implementations that adhere to section 2.3.1 in [RFC7232].

HTTP fields are generally defined to be encoded as US ASCII, so is the
ETag header. See RFC 7230, where the ETag is defined to be obs-text,
which is not compatible with UTF-8.

Furthermore, an ETag is defined as a double quoted string in RFC 7232
Section 2.3, possibly prepended by a weakness indicator.

It could be good to align the etag attribute and the ETag header.


>From Section 4.1. The etag attribute txid mechanism

    It is RECOMMENDED that the same etag txid values are used across all
    management interfaces (i.e. NETCONF, RESTCONF and any other the server
    might implement), if it implements more than one.

This suggests that the etag txid and RESTCONF ETag consider "weak" (see
RFC 7232 Sections 2.3.2. Comparison and 2.3.3. Example: Entity-Tags
Varying on Content-Negotiated Resources). HTTP ETags are tied to
respective encoding if considered to be strong. Considering the etag
txid "nc4711" this would for e.g. yang-data+xml and yang-data+json yield
two different ETags e.g. "nc4711-xml" and "nc4711-json".

RFC 8040 Section 3.4.1.2. Entity-Tag also states the following

   Note that each representation (e.g., XML vs. JSON)
   requires a different entity-tag.

It is also a possibility to instead use "weak" ETags for RESTCONF, and
then reuse the same txid value across interfaces. If the ETag is
regarded as weak, it should be prefixed with "W/", i.e. the etag txid
value from above would yield the ETag W/"nc4711".

How the ETag is regarded has implications for match when comparing.

It should at least be covered how etag and RESTCONF ETag relate.
I suggest covering this and how it could be solved in an implementation,
and also recommending how to solve it and what the implications are
when using multiple interfaces.


In Section 4.3.2.  Namespaces and Attribute Placement

   xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-patch" and

It should say ietf-yang-push, not ietf-yang-patch.


In Section 5.7.  YANG-Push, the order of establish-subscription,
modify-subscription, and the notification, should probably be different.
Since modify-subscrition sets with-etag = false, but the notification
returns an etag-value; which would be wrong after modify-subscription.

Reordering as establish-subscription, notification, modify-subscription,
would make the example correct.


--
Per