Subject: [regext] Murray Kucherawy's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS and COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 08 Apr 2020 20:08:18 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-regext-data-escrow-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I had originally included these just as comments, but since another AD brought
up the same point I'd like to discuss them:

Section 5.1.3: "This element SHOULD be present in deposits of type Incremental
or Differential."  This makes it sound like a deposit of those two types not
using this element might be non-compliant.  I suggest instead "This element is
only used in Incremental and Differential deposits."  (Or instead of "used",
maybe "meaningful".)

Section 5.1.4: " It SHOULD be present in all type of deposits."  Same issue. 
Maybe "It is valid for use in all types of deposits."

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Roman took many of my ideas, so I support his DISCUSS position and his comments.

Some of the BCP14 language in this document feels mushy.  "SHOULD/MUST take all
necessary precautions" isn't very precise, while normally
interoperability/normative language is supposed to be pretty crisp.

"gTLD" and "ccTLD" could stand to be included in the definitions section,
either by prose or by reference if there is one.

This may reveal a weak point in my understanding of XML, but Section 5.1 says
that the type of the deposit is FULL, INCR or DIFF.   Is this case-sensitive?

Section 5.1.1: Should "data-time" be "date-time"?

Section 5.1.2: About "version", although I think this is made explicit in the
XML schema in Section 6.1, I suggest a sentence be added making it clear that
this document specifies version "1.0".

Section 5.1.4, last paragraph: When would you not apply that SHOULD?  That
strikes me as MUST territory.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Apr 2020 09:45:27 -0400

> Maybe "It is valid for use in all types of deposits."

I don't understand this: "SHOULD" means that "there may exist valid
reasons in particular circumstances to ignore a particular item, but
the full implications must be understood and carefully weighed before
choosing a different course."  The text in this document isn't saying
that these make sense in the places they specify: the document *does*
mean "SHOULD" here.  Certainly, "there are no relevant items to
include" is a valid reason.

What's the point of your objection?

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Apr 2020 07:18:25 -0700

> What's the point of your objection?

The way I have always seen SHOULD used, consistent with that definition,
causes me to read 5.1.3 in a way that expects the "delete" element to be
present other than in exceptional circumstances.  However, I don't think
(and based on his comments I believe Robert agrees, though he can correct
me if not) that the absence of a "delete" element is really unusual; a diff
might genuinely -- perhaps even commonly -- only contain new items that
need to be applied to the backup with no delete actions.  The same goes for
5.1.4, where "contents" could legitimately be omitted merely because the
diff describes some canceled registrations that need to be removed.

RFC2119 also says "In particular, [2119 words] MUST only be used where it
is actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)" and I don't
thnk that's the case here.

-MSK