IETF Logo Mail Archive

Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt

Jasdip Singh <jasdips@arin.net> Thu, 18 June 2020 02:18 UTC

Return-Path: <jasdips@arin.net>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFA03A0B04; Wed, 17 Jun 2020 19:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iudv1ywGBW4n; Wed, 17 Jun 2020 19:18:26 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:110:201::51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBAA43A0B00; Wed, 17 Jun 2020 19:18:25 -0700 (PDT)
Received: from CAS02CHA.corp.arin.net (cas02cha.corp.arin.net [10.1.30.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTPS id 44501107581E; Wed, 17 Jun 2020 22:18:24 -0400 (EDT)
Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS02CHA.corp.arin.net (10.1.30.63) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Jun 2020 22:18:23 -0400
Received: from CAS01CHA.corp.arin.net ([fe80::51fb:9cc2:1f9a:288b]) by CAS01CHA.corp.arin.net ([fe80::988:2227:cf44:809%17]) with mapi id 15.00.1104.000; Wed, 17 Jun 2020 22:18:23 -0400
From: Jasdip Singh <jasdips@arin.net>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
CC: "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org>, "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Thread-Topic: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt
Thread-Index: AQHWPakf1Zc61LNNI0qJH94UyyAEfKjTzFeAgAlQcoCAANhugA==
Date: Thu, 18 Jun 2020 02:18:23 +0000
Message-ID: <F2825E26-B6C3-42C4-9115-BF8B558D4424@arin.net>
References: <159162988692.27209.10007278285596026415@ietfa.amsl.com> <ea6ab7f4-1540-0367-b3cb-b2abd2187752@iit.cnr.it> <5d79521690f0478fb51764fb90159538@verisign.com>
In-Reply-To: <5d79521690f0478fb51764fb90159538@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.136.136.37]
Content-Type: multipart/alternative; boundary="_000_F2825E26B6C342C49115BF8B558D4424arinnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/XFzSIpdrol0rjPi7HjKUgarrYpw>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 02:18:27 -0000


On Jun 17, 2020, at 9:23 AM, Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org<mailto:shollenbeck=40verisign.com@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

v2.23.0 | Report a Bug | By Email