[netconf] Re: WGLC for transaction-id-06

["Jan Lindblad (jlindbla)" <[e-mail]>]

Tom,

Thank you for your review! See my comments below marked [janl].

<tp>
Complicated! In passing, the juxtaposition of examples and definitions may make a document easy to read from start to finish - like  a novel - but I find much harder to dip into to find what I want to check up on, to comment on.  I would prefer the two to be in separate parts of the document.  This affects my comments - I find it hard to remember what I have already commented on.  I would rather be commenting on a more formal specification using examples only to aid my understanding.

[janl] I see what you mean. In the early stages of this work, I dramatically changed the structure of this document several times. This form was the one that received least resistance and made people actually read it.

Is this I-D an update to any existing document?  Metadata says not - mmmm'

[janl] Please unicast me with a more specific explanation of what needs to change. IETF draft metadata is unfortunately still not my forte.

Monotonic is for me ambiguous.  One mathematical tradition, the one I was taught, is that equality is permitted.  The other approach, which I think of as American, does not - for me, that is strictly increasing and not just monotonic.  Here I think you want the latter so I would use strictly increasing throughout.

[janl] Very good. I will change the wording as suggested. Thanks!

'entitlement installations '
 I am not familiar with this term

[janl] We all used to say “licenses” and “license installation”, but a couple of years ago I learned that is not proper terminology. It’s entitlements, not licenses, that are being installed. If others also think that an explanation or definition of this term should go in this document, I’ll add it.

dates I note are 2022. Not wrong and a pain to change but it does give to me a dated look

[janl] Ok, thanks.

Likewise the web URL are out of date - 'tools'

         "RFC XXXX: Xxxxxxxxx";
could do with the correct title so that it can be identified

[janl] Please unicast me the details, and I will fix.

prefix should be short (although two characters I see as too short) - here
  prefix ietf-netconf-txid-nmda-compare;
and the like I find rather long

[janl] Thank you for your viewpoint. My policy in recent years is to always use the module name as prefix. This is usually not short, but it makes it so much easier for newcomers to understand the meaning that it’s worth the extra characters. And this whole issue with prefixes in payload being different in NETCONF vs RESTCONF (which always uses filename as prefix) goes away. I’ll take a bet that the prefixes as we know them today will be gone in YANG 2.0 😊

   Txid:  Abbreviation of Transaction-id
**needs defining
  uniqueness
  format
  characer set
I see lower case in examples when I would have preferred Txid throughout but imagine that you want lower case to be the correct form.  Then I see
'   Txid values are opaque strings that uniquely identify a particular'
probably better as
'txid' values
And then there is
Txid History
and
   Table 1: The Txid rules for response pruning.
Mmm

[janl] Thanks. When referring to the concepts, I think the tradition is to capitalize, is it not? When referring to computer language symbols, I think the tradition is to use the case of the actual symbol? And in YANG, the tradition is to use all lowercase for the symbols.

Using strictly increasing integers in the examples when they are not required to be I think confusing - some, all? - examples should not exploit the freedom allowed.

[janl] Thanks, it’s probably a good idea to add an example using other txid naming schemes, even if one of the most common implementations probably will be strictly increasing integers, and examples using such txid values are easy to understand.

Terms defined in S.2 I always find better in alphabetic order - I can then see what is missing

[janl] I’m probably colored by legal documents (and some computer languages) where definitions can only refer to concepts previously defined. Since there are only 6 terms defined here, and they are easy to read and understand when consumed from top to bottom as listed, I think I’ll leave it as is, unless others on this list also chime in.

', but all txid mechanisms would    have a special "txid-request" txid value (e.g., "?") '
how do I know what the special value is - as with strictly increasing, a counter example would be good.  Also, the text implies to me that there is a syntax but the I-D does not appear to spell out what it is.  Like using strictly increasing in the examples while saying they need not be strictly increasing!

[janl] This document describes i) general principles for all txid-mechanisms (section 3) and ii) the details for two specific txid-mechanisms (etag and last-modified, section 4.1 and 4.2). It may have been wiser to split the document into two or three drafts, to make this distinction clearer. As it is now, the verbiage in the section 3 is often stating things generic like   (e.g. “?”)    since it only describes principles and not protocol.

'.  For example, clients must not assume
Well, um different txid = different version see above

'   that servers use a txid value scheme that reveals information about
   the temporal sequence of txid values'
Again problematic to me; txid needs rules but must not have rules lest they expose information!

[janl] Txids do expose information, but in some implementations that information does not include temporal sequence.

'The most recent change seems to have been an update to ace R8 and R9.'
How do we know what is most recent if the values have no semantics, which is what the definition says

[janl] This is only an example. The “seems to have been an update…” comes from the general NOTE: In the etag examples below, we have chosen to use a txid value consisting of "nc" followed by a monotonously increasing integer. This is convenient for the reader trying to make sense of the examples, but is not an implementation requirement. An etag would often be implemented as a "random" string of characters.

'      monotonously increasing integer as txid.  '
An interesting choice of adverb.

[janl] Would “strictly increasing” be a better choice of words?

s.3.4
rather large, better subdivided IMHO

[janl] It’s very long indeed. I will think of some subheadings 3.4.1 etc.

'Servers MUST NOT ever use '
'ever' I think redundant

[janl] Ok, will remove.

'  Figure 6: The txids are updated on all Versioned Nodes that were
        modified themselves or have a child node that was modified.'
For me this is a key concept that I did not pick up from the parts of the text that were not examples.

[janl] Ok, thanks. Will think up some language to fix that.

'    return the special txid-unknown value (e.g., "!") or the s-txid'
What is it if it is not the '!' (which is only an example)?

[janl] See discussion above about the principles in section 3 and the protocols in section 4. In section 3, there are examples to help navigate to section 4.

Thank you very much for the feedback, Tom! An updated version will follow.

Best Regards,
/jan