Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

Tobias Sattler <sattler@united-domains.de> Tue, 22 December 2020 07:43 UTC

Return-Path: <sattler@united-domains.de>
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 A973B3A0C11 for <regext@ietfa.amsl.com>; Mon, 21 Dec 2020 23:43:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=united-domains.de
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 w5iPRtWhB91e for <regext@ietfa.amsl.com>; Mon, 21 Dec 2020 23:43:26 -0800 (PST)
Received: from falbalka.udag.de (intmail.udag.de [89.31.137.125]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06B83A0C0D for <regext@ietf.org>; Mon, 21 Dec 2020 23:43:25 -0800 (PST)
From: Tobias Sattler <sattler@united-domains.de>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=united-domains.de; s=ud20150520; t=1608623003; bh=0QYzsTIccaNj/0/5L7W16mgHXUgwSj2LLjN7Fk5hDpE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=coD6DGyNC8vEF3VawKLtypWsNaySMIiZXeXH/YZmBR4yYH8lVLOCs3TJMZQdAYb0f gzX3AAVQcI27ItLxmMfXPHHBbPlsoO0NeMiRZ9B2TJJ+SdhMF/MloApy0ziQ4YeHRV f/eFjTv+kXZgVshStaN1es7kGeQ/XJzs2gE9eqhP+5dHw0BZ2APzphRYjAs1XKTJXm 1zTULslEWjA6hJYmzpjlXVG/s0JUidF4NHzaWyxhPBlS1v1aZP2NH9PpR1i1UADHkW NBuHqL//W6zCiKQU7kuBIhK34lrZo4ISi3gFnf420HkXiRJp823PBKntCIg/1W4/oR pnKkHVBV/2zmA==
Message-Id: <2AB49799-41F3-49EA-B4E5-653711E81278@united-domains.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3ACB7D01-2E25-4414-8A64-51B48D4FF2C2"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 22 Dec 2020 08:43:22 +0100
In-Reply-To: <69B8F4E6-EACE-4F24-86F0-9FA23DD25E48@united-domains.de>
Cc: "regext@ietf.org" <regext@ietf.org>
To: "Gould, James" <jgould@verisign.com>
References: <249514D7-148E-4B28-96EB-A34E1390F6DA@verisign.com> <69B8F4E6-EACE-4F24-86F0-9FA23DD25E48@united-domains.de>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Authentication-Results: falbalka.udag.de; auth=pass smtp.auth=sattler smtp.mailfrom=sattler@united-domains.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/ZoBJ0z6OaD37Rw8Lz4mcC0mVRp0>
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.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: Tue, 22 Dec 2020 07:43:32 -0000

Hi Jim,

I prepared a new version on GitHub in the interim.
https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt

I addressed your feedback, with two exceptions:

1.) <maint:start> and <maint:end> shouldn’t be optional, therefore, I removed the minOccurs in the schema. We set it to zero, when trying to figure out how to handle the inactive status. With removing the status, we reverted it back.

2.) In terms of "Migrating to Newer Versions of This Extension”, we need a bit of time to check that.

Thanks,
Tobias

> On 22. Dec 2020, at 07:43, Tobias Sattler <sattler@united-domains.de> wrote:
> 
> Hi Jim,
> 
> Thanks for your feedback.
> 
> We will prepare a new version, and address your points.
> 
> Best,
> Tobias
> 
>> On 21. Dec 2020, at 23:00, Gould, James <jgould@verisign.com <mailto:jgould@verisign.com>> wrote:
>> 
>> Tobias,
>>  
>> Thank you for the update.  It looks like you addressed my feedback.  In reviewing draft-ietf-regext-epp-registry-maintenance-07, I have the below additional feedback:
>>  
>> Section 1.1 “Terminology and Definitions”
>> The first key words paragraph needs to be revised to the following based on the latest published EPP RFCs:
>>                                                               i.      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <https://tools.ietf.org/html/bcp14> [RFC2119 <https://tools.ietf.org/html/rfc2119>] [RFC8174 <https://tools.ietf.org/html/rfc8174>] when, and only when, hey appear in all capitals, as shown here.
>> I’m not sure what drove the change to the use of “C:” and “S:”, but I would revert it to the way it was in draft-ietf-regext-epp-registry-maintenance-06.  The way it was in draft-ietf-regext-epp-registry-maintenance-06 matched what has gone through the RFC editor for the latest EPP extensions. 
>> Potential Need - Section 2 “Migrating to Newer Versions of This Extension”
>> The latest EPP extensions included a Migrating to Newer Versions of This Extension” section to provide guidance on how to support transitioning to a newer version of the extension.  One difference is that the Login Security Extension and the Registry Fee Extension RFCs are command response extensions and the Registry Maintenance Notifications draft is an object extension, so transitioning is slightly different.  One aspect that is unique with the Registry Maintenance Notifications is the poll messages.  What happens when the client supports multiple versions of the maintenance extension that is supported by the server and what happens of the client doesn’t support any of the versions supported by the server.  My recommendation is to return the latest version supported by the client and server, and to leverage draft-ietf-regext-unhandled-namespaces (section 6) for the latter case.
>> Section 2.3 Maintenance Elements
>> The word Indicates can be removed when describing each of the elements.  For example, for the <maint:systems> element could read “One or more <maint:system> elements…”, and the <maint:name> element could read “The name of the affected system…”.
>> Use “an A-label according to [RFC5891]” instead of “A-label according [RFC5891]”, such as for the <maint:host> element, “…which SHALL be an A-label according to [RFC5891]”.
>> For the <maint:environment> element, update ‘…attribute type is…’ to ‘…attribute “type” is …’, and update “…SHOULD either be…” to “…MUST either be…”, since the environment element is an enumerated value in the XML schema.  I would reuse the language for the “name” attribute from the Launch Phase Extension, such as ‘For extensibility, the <maint:environment> element includes an OPTIONAL “name” attribute that can define the name the custom environment when the <maint:environment> element “type” attribute has the “custom” value.  For example, for the custom “marketing” environment, the <maint:environment> element should be <maint:environment type=”custom” name=”marketing”/>’.  
>> For the <maint:end> element, revise “…equal or greater than…” to “…equal to or greater than…”.   
>> For the <mait:reason> element, update “…SHOULD either be…” to “…MUST either be…”, since the reason element is an enumerated value in the XML schema.
>> For the <maint:detail> element, update “Contains URI…” to “OPTIONAL URI…”. 
>> For the <maint:description> element, update “A freeform description…” to “OPTIONAL freeform description…”.
>> For the <maint:tlds> element, update “…contains the following child elements.:” to “…contains one or more <maint:tld> child elements:”
>> For the <maint:tld> element, you may want to broaden this past a TLD; although I realize that the vast majority of the maintenances will be associated with TLDs.  In the Registry Mapping (https://tools.ietf.org/html/draft-gould-carney-regext-registry <https://tools.ietf.org/html/draft-gould-carney-regext-registry>), the term “zone” was used instead with a description as typically being a top-level domain name.  I’m not proposing to change the element name, but to broaden the description to support a broader set of authoritative zones.  An example is “The affected top-level domain name or registry zone, which SHALL be an A-label according to [RFC5891].”
>> For the <maint:invention> element, update “The <maint:intervention> element…” to “The OPTIONAL <maint:intervention> element…”.
>> Section 3.1.3.2 “Info Maintenance List”
>> From the XML Schema it also looks like the <maint:start> and <maint:end> elements are optional, so I would update them to include the “OPTIONAL” key word like what was done for the <maint:upDate> element.  Is it intended for the <maint:start> and <maint:end> elements to be optional? 
>> Section 4.1 “Registry Maintenance EPP Mapping Schema”
>> The addrType element removed the “ip” attribute and the reference to the “maint:ipType”. 
>>                                                               i.      The associated “ipType” type can be removed from the XML schema
>>                                                             ii.      The XML namespace should be bumped up from 0.1 to 0.2, as in “urn:ietf:params:xml:ns:epp:maintenance-0.2” throw-out the draft, since this is a material XML schema change.
>> Section 5.1 “XML Namespace”
>> The maintenance schema registration needs to be changed from version “1.0” to “0.1”, but will actually change to “0.2” based on the feedback above.  Eventually “0.2” will be changed to “1.0” when the draft is ready for WGLC, but for now it should reflect the namespace version defined in the draft.
>>  
>> -- 
>>  
>> JG
>> 
>> <image001.png>
>> 
>> James Gould
>> Fellow Engineer
>> jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>
>> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>> 
>> Verisign.com <http://verisigninc.com/>
>>  
>> From: Tobias Sattler <sattler@united-domains.de <mailto:sattler@united-domains.de>>
>> Date: Friday, December 11, 2020 at 5:06 PM
>> To: James Gould <jgould@verisign.com <mailto:jgould@verisign.com>>
>> Cc: "regext@ietf.org <mailto:regext@ietf.org>" <regext@ietf.org <mailto:regext@ietf.org>>
>> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt
>>  
>> Hi Jim,
>>  
>> We addressed your feedback and submitted the new version 07.
>>  
>> Thanks,
>> Tobias
>> 
>> 
>>> On 9. Dec 2020, at 08:37, Tobias Sattler <sattler@united-domains.de <mailto:sattler@united-domains.de>> wrote:
>>>  
>>> Hi Jim, 
>>>  
>>> Thank you for your additional feedback. We are currently preparing a new version, and will incorporate that too.
>>>  
>>> Best,
>>> Tobias
>>> 
>>> 
>>>> On 8. Dec 2020, at 21:42, Gould, James <jgould@verisign.com <mailto:jgould@verisign.com>> wrote:
>>>>  
>>>> Tobias,
>>>>  
>>>> I reviewed the updates made in draft-ietf-regext-epp-registry-maintenance-06 and they look to have addressed my last feedback.  I have some additional feedback below:
>>>>  
>>>> 1.       Section 2.3 “Maintenance Elements”
>>>> a.       The sentences “For creating a new maintenance the attribute <maint:crDate> MUST be set and the attribute <maint:upDate> SHALL NOT be present.” and “For updating a maintenance the attributes <maint:crDate> and <maint:upDate> MUST be set.” seem out of place.  I recommend removing these sentences and leave the definition of when the <maint:upDate> is set when describing that element. 
>>>> b.       I would default to the elements be required like other EPP RFCs and defining the optional elements using the OPTIONAL key word.  For example:
>>>>                                                                                                                                        i.      <main:id>
>>>> 1.       Server unique identifier for the maintenance with an OPTIONAL “msg” attribute that includes a human-readable description of the maintenance.  When the “msg” attribute is set, an OPTIONAL “lang” attribute MAY be present to identify the language if the negotiated value is something other than the default value of “en” (English).      
>>>> a.       The “lang” attribute is defined in the XML schema but not described in the text. 
>>>>                                                                                                                                      ii.      <main:systems>
>>>> 1.       One or more <maint:system> elements that are affected by the maintenance.  The <main:system> element contains the following child elements:
>>>> a.       <maint:name>
>>>>                                                                                                                                                                                                                i.      Indicates the name of the affected system, which as “EPP”, “WHOIS”, “DNS”, “Portal”, etc.. 
>>>> b.       …
>>>> c.       <maint:start>
>>>>                                                                                                                                                                                                                i.      Contains the date and time that of the start of the maintenance. 
>>>> 1.       The format of the date and time is already covered by section 2.2 “Dates and Times”.
>>>> d.       <maint:end>
>>>>                                                                                                                                                                                                                i.      Contains the date and time of the end of the maintenance.  The <maint:end> element MUST be equal to or greater than the <maint:start> element.
>>>> 1.       The format of the date and time is already covered by section 2.2 “Dates and Times”.
>>>> e.       …
>>>> f.        <maint:description>
>>>>                                                                                                                                                                                                                i.      A freeform description of the maintenance without having to create and traverse an external resource defined by the <maint:detail> element.  An OPTIONAL “lang” attribute MAY be present to identify the language if the negotiated value is something other than the default value of “en” (English).
>>>> 1.       The “lang” attribute is defined in the XML schema but not described in the text. 
>>>> g.       <maint:crDate>
>>>>                                                                                                                                                                                                                i.      Contains the date and time of maintenance object creation.
>>>> 1.       The format of the date and time is already covered by section 2.2 “Dates and Times”.
>>>> h.       <maint:upDate>
>>>>                                                                                                                                                                                                                i.      Contains the date and time of the most recent maintenance-object modification.  This element MUST NOT be present if the maintenance object has never been modified.
>>>> 1.       The format of the date and time is already covered by section 2.2 “Dates and Times”.
>>>> 2.       Section 3.1.3 “EPP <info> Command”
>>>> a.       I would revise the second paragraph to read like:
>>>>                                                     i.   The <maint:info> element MUST contain a child element. It is either the <maint:id> element, described in Section 3.1.3.1, to query for a specific maintenance item or the <maint:list> element,  described in Section 3.1.3.2, to query all maintenance items.
>>>> 3.       Section 3.1.3.1 “Info Maintenance Item”
>>>> a.       I would revise the first paragraph to read like:
>>>>                                                     i.   The information on a specific maintenance item can be retrieved by using the <info> command with the <maint:info> element and the <maint:id> child element, defined in Section 2.3.  If the maintenance identifier does not exist, the server MUST return an EPP error result code of 2303 [RFC5730].
>>>> 1.   The second paragraph can be removed.
>>>> 4.       Section 3.1.3.2 “Info Maintenance List”
>>>> a.       I would revise the first paragraph to read like:
>>>>                                                     i.   The information for a list of maintenance items can can be retrieved by using the <info> command with the <maint:info> element and the empty <maint:list> child element.  Server policy determines if previous maintenances will be included in the list of maintenance items.
>>>> b.  Change “The <maint:infData> element contains the <maint:list> element a list of <maint:listItem> elements.” to “The <maint:infData> element contains the <maint:list> element with zero or more <maint:listItem> child elements.
>>>> 5.       Section 3.1.4 “EPP <poll> Command”
>>>> a.       Revise the sentence “The poll message applies whenever the domain name registry creates, or delete maintenance” to “A poll message applies when a maintenance is created, updated, or deleted.”.  
>>>>                                                                                                                                        i.      The domain name registry is not defined anywhere and it typically is referred to as “the server”. 
>>>> b.       I would revise the second paragraph to read like and I would include it as the last sentence of the first paragraph:
>>>>                                                                                                                                        i.      The <maint:infData> element contains the <maint:item> element defined in Section 2.3. 
>>>> c.       I would remove the third paragraph “Please see the definition of <maint> elements in Section 2.3”.
>>>> 6.       Section 4 “Formal Syntax”
>>>> a.       I would replace BEGIN with <CODE BEGINS> and END with <CODE ENDS>.
>>>>                                                                                                                                        i.      This change was requested by the IESG with the Login Security Extension (https://tools.ietf.org/html/rfc8807 <https://secure-web.cisco.com/1NXfHrMjEk_QThvoDHxgqlNjDR89du6BXWlcuvLZEf8UDoNHYzdwww7OYtf_3_svVaQ168qCYexcP6r2b-7GdMbStC2R4Z1CsNNFre2O-FdOgOpStyCVZYsQkdW1x_DCxZzoxLIAiIr34tuigeSCYjouXSpWvsp-i9Z8cVn7s0C5q3rlJYucPdkISwMbbNcN6_DKXWzL87TcxSnviE9u3W9h1u7vyhIxyKkfmFB9uFLFTC0zhPBU2Wq9qRm74l1396z6bs1dtsqRenPCRMmw7zXMCoywlGlS0cH_lzxdNRR8/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8807>)  
>>>>  
>>>> Thanks,
>>>>  
>>>> -- 
>>>>  
>>>> JG
>>>> 
>>>> <image001.png>
>>>> 
>>>> James Gould
>>>> Fellow Engineer
>>>> jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>
>>>> 
>>>> 703-948-3271
>>>> 12061 Bluemont Way
>>>> Reston, VA 20190
>>>> 
>>>> Verisign.com <http://secure-web.cisco.com/1cy2sYeZLPXNvVtqZme9DO8ubODoFoMGL5cjZ5vGsY_WFi7opO-75vcCXp1Bw9ATUxjGHIOyrut4txTnMabLKdtWilNolpHWPpa67U8zG37n6yC75Wjjz3axmYjzrWsQf-RoSnsA3mqegJg5mVosvtoQ3HsOEYTptUPF4XQ0SSYgBsQP26ukNHDijUFCf1XyfDeL1tv4KhQqE2heXlyJigGuk3sAhsxtYHigNeJc84Jk3NRqTO_6ajqJO0UNqWbL_Iyeeuo5QVqpzwGsjTHQZyZ7BdaNoOuvjTirap30G8ek/http%3A%2F%2Fverisigninc.com%2F>
>>>>  
>>>> From: Tobias Sattler <sattler@united-domains.de <mailto:sattler@united-domains.de>>
>>>> Date: Tuesday, December 8, 2020 at 3:09 AM
>>>> To: James Gould <jgould@verisign.com <mailto:jgould@verisign.com>>
>>>> Cc: "regext@ietf.org <mailto:regext@ietf.org>" <regext@ietf.org <mailto:regext@ietf.org>>
>>>> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt
>>>>  
>>>> Hi Jim, 
>>>>  
>>>> We addressed your feedback and submitted the new version.
>>>>  
>>>> Thanks,
>>>> Tobias
>>>> 
>>>> 
>>>> 
>>>>> On 1. Dec 2020, at 15:58, Tobias Sattler <sattler@united-domains.de <mailto:sattler@united-domains.de>> wrote:
>>>>>  
>>>>> Hi Jim, 
>>>>>  
>>>>> Thank you for your swift feedback.
>>>>>  
>>>>> We will go through it and make the adjustments where needed.
>>>>>  
>>>>> Best,
>>>>> Tobias
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 1. Dec 2020, at 15:35, Gould, James <jgould=40verisign.com@dmarc.ietf.org <mailto:jgould=40verisign.com@dmarc.ietf.org>> wrote:
>>>>>>  
>>>>>> In reviewing draft-ietf-regext-epp-registry-maintenance-05, below is my feedback:
>>>>>>  
>>>>>> 1.       Replace “defnition” with “definition” in two places.
>>>>>> 2.       Section 2.3 Maintenance Elements 
>>>>>> a.       I would modify the description of the <maint:item> element.  Specifically, change the second sentence to read like “This element is used in a maintenance item EPP <info> response and <poll> message.”.
>>>>>> 3.       Section 3.1.3.1 “Query one maintenance item” 
>>>>>> a.       The name “Query one maintenance item” could be shortened to “Info Maintenance Item”.
>>>>>> b.       I would explicitly define the Info Maintenance Item command element (<maint:id>) without making the reference to Section 2.3, since Section 2.3 defines the Info Maintenance Item Response. 
>>>>>> c.       The command example incorrectly references <maint:impact>blackout</maint:impact> instead of <maint:impact>full</maint:impact>.
>>>>>> d.       The dates in the response example should be updated to more recent dates (e.g., update 2017 to 2020)
>>>>>> e.       I would define the response similar to:
>>>>>>                                                                i.      When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <maint:infData> element that identifies the maintenance namespace.  The <maint:infData> element contains the <maint:item> element defined in Section 2.3.
>>>>>> 4.       Section 3.1.3.2 “Query maintenance list” 
>>>>>> a.       The name could be updated to “Info Maintenance List”.
>>>>>> b.       I would explicitly define the Info Maintenance List element (<maint:list/>), which is an empty element to indicate an Info Maintenance List command.
>>>>>> c.       The dates in the response example should be updated to more recent dates (e.g., update 2017 to 2020)
>>>>>> d.       I would define the response similar to:
>>>>>>                                                                i.      When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <maint:infData> element that identifies the maintenance namespace.  The <maint:infData> element contains the <maint:list> element with a list of <maint:listItem> elements.  The <maint:listItem> element contains the following child elements:
>>>>>> 1.  <maint:id>: <maint:id> defined in Section 2.3.
>>>>>> 2.  <maint:start>: <maint:start> defined in Section 2.3.
>>>>>> 3.  <maint:end>: <maint:end> defined in Section 2.3.
>>>>>> 4.  <maint:crDate>: <maint:crDate> defined in Section 2.3.
>>>>>> 5.  <maint:upDate>: OPTIONAL <maint:upDate> defined in Section 2.3.
>>>>>> 5.       Sect 3.1.4 “EPP <poll> Command” 
>>>>>> a.       The dates in the poll response example should be updated to more recent dates (e.g., update 2017 to 2020)
>>>>>>  
>>>>>> -- 
>>>>>>  
>>>>>> JG
>>>>>>  
>>>>>>  
>>>>>>  
>>>>>> James Gould
>>>>>> Fellow Engineer
>>>>>> jgould@Verisign.com <mailto:jgould@Verisign.com> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>>
>>>>>>  
>>>>>> 703-948-3271
>>>>>> 12061 Bluemont Way
>>>>>> Reston, VA 20190
>>>>>>  
>>>>>> Verisign.com <http://verisign.com/> <http://verisigninc.com/ <http://secure-web.cisco.com/1Q7FeDJQhN16gb_93Fht5OZbhpGmfeKUcS0zReQ25sb0CY45l_P0DxHSTU-CpHKvynF3t7biGXCqV74SwtWXpTdeyLPeGF4wuSFs-eOdyUaG2ECdXp9yRPUXKIRvHVQMQTGNXCETjvIgcgjx2UfVz1r7VK5AwnUIL88iY1a9SMqNCNRy6EhkW-Z2Ee4JHOCCs96Jy0RBIn6annwmp7E8dKYWo2r1KSGXwgkLrSB65l2yCKhTTfx67G2_mtmalqeRqbCgPwXB5fMMJayvqMmp5mTY2jM8e0Tf4tMdRyBIv170/http%3A%2F%2Fverisigninc.com%2F>>
>>>>>>  
>>>>>> On 12/1/20, 7:32 AM, "regext on behalf of internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>" <regext-bounces@ietf.org <mailto:regext-bounces@ietf.org> on behalf of internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>> wrote:
>>>>>>  
>>>>>>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>>>     This draft is a work item of the Registration Protocols Extensions WG of the IETF.
>>>>>>  
>>>>>>             Title           : Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP)
>>>>>>             Authors         : Tobias Sattler
>>>>>>                               Roger Carney
>>>>>>                               Jody Kolker
>>>>>>                 Filename        : draft-ietf-regext-epp-registry-maintenance-05.txt
>>>>>>                 Pages           : 20
>>>>>>                 Date            : 2020-12-01
>>>>>>  
>>>>>>     Abstract:
>>>>>>        This document describes an Extensible Provision Protocol (EPP)
>>>>>>        mapping for registry's maintenance notifications.
>>>>>>  
>>>>>>  
>>>>>>     The IETF datatracker status page for this draft is:
>>>>>>     https://secure-web.cisco.com/1li8mLoCxeVjC53-tGvYzKD4YcjkoE6Ev-IZRxp8KydPQ9dy_dgHOxizxSu23hsx4RZVoh7T-GMHV8zzq0pNGEZqcIUucZuoE6CiU1K8nM-bkcRygXmVdp3F6IUnzumkKuauScX42WmKG3nZr5M5pzix-u_BLsV61qGnHT0yCC-E7kdUw4ZjoJ_Gs8-hgv9eabShu15czchF07EvEhnXBjZGQ3xXpcztwDy3pitq834n2SIblYBWUMsF2dJUQTlJi7Q9o-v8tOLMf5xtlZWSLcA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F <https://secure-web.cisco.com/1li8mLoCxeVjC53-tGvYzKD4YcjkoE6Ev-IZRxp8KydPQ9dy_dgHOxizxSu23hsx4RZVoh7T-GMHV8zzq0pNGEZqcIUucZuoE6CiU1K8nM-bkcRygXmVdp3F6IUnzumkKuauScX42WmKG3nZr5M5pzix-u_BLsV61qGnHT0yCC-E7kdUw4ZjoJ_Gs8-hgv9eabShu15czchF07EvEhnXBjZGQ3xXpcztwDy3pitq834n2SIblYBWUMsF2dJUQTlJi7Q9o-v8tOLMf5xtlZWSLcA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F>
>>>>>>  
>>>>>>     There are also htmlized versions available at:
>>>>>>     https://secure-web.cisco.com/1S6_PU9v_ZkWX9nWp6WP47Od0hWHICawFbyNoykQ6CD7yvG7EpPWyV2XcTGNB60pzVywp_LjRV-wPBbVt7XptxNhGqCGxm4Zihg4MoaiCDcHXbrQPw3IzXF30wCX4DTMCQD2S9PmF2mpQ9i74fwPzhclx0RtAyhDG-mI0VwhiH9_PzB9t57cO3jvzWA3fEIgSL6H6z71YjNr5CgarKpreOKxtbWxyy2gQw1kAfy1waFnV5vIif11v_zgPjEL7IUsUNva6DcWIjZMhYqspuhwKAaSa8M5u8D3iJ5Jj7ByMf-8/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-epp-registry-maintenance-05 <https://secure-web.cisco.com/1S6_PU9v_ZkWX9nWp6WP47Od0hWHICawFbyNoykQ6CD7yvG7EpPWyV2XcTGNB60pzVywp_LjRV-wPBbVt7XptxNhGqCGxm4Zihg4MoaiCDcHXbrQPw3IzXF30wCX4DTMCQD2S9PmF2mpQ9i74fwPzhclx0RtAyhDG-mI0VwhiH9_PzB9t57cO3jvzWA3fEIgSL6H6z71YjNr5CgarKpreOKxtbWxyy2gQw1kAfy1waFnV5vIif11v_zgPjEL7IUsUNva6DcWIjZMhYqspuhwKAaSa8M5u8D3iJ5Jj7ByMf-8/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-epp-registry-maintenance-05>
>>>>>>     https://secure-web.cisco.com/1XNpISpXfN8MQw1PEsPccAZ0_sZLESxXSKZD_sTvZwJ0QIufYJqXbGF7wdOTdR-pMMnOEH9LNrozfFZ1A4is0CHnJTuDLvhWgwwQ6ZQnpUxrk49oTY2HM7dgf9sbMhl_d2NuioFX8zj9eDSza6SYpZNMAQWA6mWsaobZSEHoaDcBsvWALD0as2Ko7xiWtIyrzb8YC5d0FfZnjNNkjDeILwCeXKqeU6UPGFZ1_1-2vHpW1yad8vgx2YnKBz42vnOcggnzk5g6kBEpntmhY1sKUkA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-registry-maintenance-05 <https://secure-web.cisco.com/1XNpISpXfN8MQw1PEsPccAZ0_sZLESxXSKZD_sTvZwJ0QIufYJqXbGF7wdOTdR-pMMnOEH9LNrozfFZ1A4is0CHnJTuDLvhWgwwQ6ZQnpUxrk49oTY2HM7dgf9sbMhl_d2NuioFX8zj9eDSza6SYpZNMAQWA6mWsaobZSEHoaDcBsvWALD0as2Ko7xiWtIyrzb8YC5d0FfZnjNNkjDeILwCeXKqeU6UPGFZ1_1-2vHpW1yad8vgx2YnKBz42vnOcggnzk5g6kBEpntmhY1sKUkA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-registry-maintenance-05>
>>>>>>  
>>>>>>     A diff from the previous version is available at:
>>>>>>     https://secure-web.cisco.com/1KSWNQPojpKmLvO_WIQ_irF2tlGnvVG0NPX5XV846TrqHNQ1N4Nnh4PreFg5v0DC0wn9U0sbBn1u2ZrTcuObqRweYR6CvUQFmHQTv8zi_xPnobTWzspaoT_WO3Hmp5APY41nDiHh4IuQkqTPiXNq6tATib3PopqsT9kHFgCTslmKqRe9GH3jhJgNoPxh4lTox7f5sDssSMM_Sx3dUV40K0iag_k-wRIhnkeBZwf9P6Dw7kl1tClmighR8iEjHf2cO1gZhmKA_WTzmYvg_vwL-vvEtrutRQMo0TyWX7OTMgOk/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-epp-registry-maintenance-05 <https://secure-web.cisco.com/1KSWNQPojpKmLvO_WIQ_irF2tlGnvVG0NPX5XV846TrqHNQ1N4Nnh4PreFg5v0DC0wn9U0sbBn1u2ZrTcuObqRweYR6CvUQFmHQTv8zi_xPnobTWzspaoT_WO3Hmp5APY41nDiHh4IuQkqTPiXNq6tATib3PopqsT9kHFgCTslmKqRe9GH3jhJgNoPxh4lTox7f5sDssSMM_Sx3dUV40K0iag_k-wRIhnkeBZwf9P6Dw7kl1tClmighR8iEjHf2cO1gZhmKA_WTzmYvg_vwL-vvEtrutRQMo0TyWX7OTMgOk/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-epp-registry-maintenance-05>
>>>>>>  
>>>>>>  
>>>>>>     Please note that it may take a couple of minutes from the time of submission
>>>>>>     until the htmlized version and diff are available at tools.ietf.org <http://secure-web.cisco.com/1VYNKwPIGDGqP4zEybRxweq-ZAXkhaUb5DyFGW-xpwvzPr9V58uziKa0EH4p5F5Pdz9cu6fXJevjifJ7vkdf8bD2E-TkxqnhdCDhshvDBkZBFZNkqmsUZAQ8kSseoXCU-XoX2gRoh8iDMfVLR0wZxo7kIKoagrwKGI0OBbbrprvBiwp9r0dr1kESUpXETHie4_I_bQOplX6ySaWjRmUjuHa9CcqOqgXTsrWcJGXDVV5yRgoRl010b9xHjEwXk0CriP6EV_pX_5i3gzJK6VoqGy0Ud8pgRtDOU9V5qLtA1Ybw/http%3A%2F%2Ftools.ietf.org%2F>.
>>>>>>  
>>>>>>     Internet-Drafts are also available by anonymous FTP at:
>>>>>>     ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>>>>>  
>>>>>>  
>>>>>>     _______________________________________________
>>>>>>     regext mailing list
>>>>>>     regext@ietf.org <mailto:regext@ietf.org>
>>>>>>     https://secure-web.cisco.com/1v2GmNiRW6LGBp9t0VmF4qf64EGWy5imLishTLvSm672F9aofELXoa5Vvzw1jGfadWXdD85jL-lLbbuTU_ugz0VCc3te-397rOJjLDv0NR80D6etQe8LMdvw1kjzNczvhvXphV0JlOT7ke70TQWpwNhQZbRG2bUBJ2VdVkHRsWCc-5mRwbrwOS6uEMUXD4CDYxVLSUsWuLlQ7rOH5viQJMbIasArywqdHgWETm7pcWtK-vh4Ryzg6QJFYoaSFdee8QhZ0jU7QcWc7RqVs4wPHeUGtcrcAic59uemX_otwo8s/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1v2GmNiRW6LGBp9t0VmF4qf64EGWy5imLishTLvSm672F9aofELXoa5Vvzw1jGfadWXdD85jL-lLbbuTU_ugz0VCc3te-397rOJjLDv0NR80D6etQe8LMdvw1kjzNczvhvXphV0JlOT7ke70TQWpwNhQZbRG2bUBJ2VdVkHRsWCc-5mRwbrwOS6uEMUXD4CDYxVLSUsWuLlQ7rOH5viQJMbIasArywqdHgWETm7pcWtK-vh4Ryzg6QJFYoaSFdee8QhZ0jU7QcWc7RqVs4wPHeUGtcrcAic59uemX_otwo8s/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>>>>>>  
>>>>>> _______________________________________________
>>>>>> regext mailing list
>>>>>> regext@ietf.org <mailto:regext@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/regext <https://secure-web.cisco.com/1Y_PQMq7QTR4iihjpm3df5cR1Qq7sXkxY5gP3Y6KD_2icfo7jpLfQN9Fcnek1QSAPnhiynbR6pC2rmwO60bbuzjONQleO-rjKpTuTOBbY6kJrDhq44dqKX24ZJagzEa2Xv2OrJGAVwLmC8Jnd56n5SZIaD6CEgq0MFVkntEt-BDoiGpcJS-30v-y7RKUaac00nKwRCvhOeyuDMTNJn15VbdMMMdTqR9Za00Xlq_VaVIcn6MSmXLSPrPc6wEzJcX6muH0Bwmx0H9ejnOBx8rK0aTvF54Wzu6Ul-gEuXqOOd3k/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>>>>>  
>>>> 
>>>>  
>>> 
>>>  
>>> _______________________________________________
>>> regext mailing list
>>> regext@ietf.org <mailto:regext@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext