From: Jasdip Singh <jasd...@arin.net> Sent: Wednesday, June 17, 2020 10:18 PM To: Hollenbeck, Scott <shollenb...@verisign.com> Cc: mario.loffr...@iit.cnr.it; regext@ietf.org; internet-dra...@ietf.org; i-d-annou...@ietf.org Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt On Jun 17, 2020, at 9:23 AM, Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org<mailto:shollenbeck=40verisign....@dmarc.ietf.org>> wrote: 7) Section 10.2.3 - The definition of "last changed" event type seems to be inconsistent with "upDate" defined in RFC 5731,5732,5733. For example, I report an extract from RFC5731 here in the following: - An OPTIONAL <domain:upDate> element that contains the date and time of the most recent domain-object modification. This element MUST NOT be present if the domain object has never been modified. So, should we redefine the "last changed" event accordingly? Should we change all the examples where "last changed" date is equal to "registration" date? [SAH] I think we can leave this one alone. The meaning seems clear to me since we also have the registration event. We could change the examples, but before I do that I'd like to know what people have implemented. Do servers return this value for an object that has been registered, but never updated? +1 For a registered but never updated scenario, we return the “last change” date as well, equal to the “registration” date. Jasdip [SAH] Thanks for the feedback, everyone. I’ll leave this one alone.
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
