I completed the action item to see how existing registrar notices map to the
elements defined in this section. There was a sidebar with the draft editors
that I want to ensure gets on the record. I want to thank the draft editors
with being so responsive. Most of the identified gaps have been addressed in
draft-ietf-regext-epp-registry-maintenance-10. Below is the list of gaps and
the status of each gap:
1. The name of the maintenance is missing
* This change was incorporated into
draft-ietf-regext-epp-registry-maintenance-10.
* The <maint:id> element included an optional “msg” attribute that had
the purpose of representing the human-readable name of the maintenance;
although it was referred to as human-readable description. My recommendation
was to change the attribute from “msg” to “name” and to revise the description
to reflect the purpose by changing “description” to “name”.
2. The type of the maintenance is missing
* This change was incorporated into
draft-ietf-regext-epp-registry-maintenance-10.
* There are maintenance types included in some of the registry
agreements that should be included in the notice. The types are inconsistent,
so my recommendation was to add an optional token element for the type.
3. Need for a formatted HTML description, since notices currently include
formatted HTML content.
* We did not come to agreement on this item, so this remains an open gap.
* The <maint:description> element is of type “string” and can support
plain or HTML text. The HTML text would use XML escaping, but that is not an
issue for the producer or consumer of the notification when using an XML
Transformer and XML Parser. My recommendation was to add a “type” attribute to
the <maint:description> element with the enumerated values of “plain” and
“html”, with a default value of “plain”. The use of MIME came up, but I
believe that may be too broad to address the gap. I believe that the
description should support either plain text or formatted HTML text. The use
of the link in the <maint:detail> element should not be a requirement to
provide a formatted description for the maintenance. I view the <maint:detail>
element as useful when linking to binary content, since the text description
(plain or formatted) should be supported by the <maint:description> element
directly.
4. The impact element values of “full” and “partial” are a little unclear.
* No action required unless clarification needs to be made explicit in
the draft.
* The deployments are typically handled via either bringing down the
VIP, which would match “full”, or handled via a rolling deployment, which may
match “partial”. The reply from the editors was “If the system is completely
offline, then it is “full”. If it is a rolling update, then it is “partial”.”
I’m fine based on the clarification, but I’m unsure whether this needs to be
made explicit in the draft for clarification down the line.
5. How to signal the maintenance of an entire system versus the maintenance
of an individual or set of TLDs on the system
* We did not come to agreement on this item, so this remains an open
issue that requires feedback from the WG.
* The maintenance object includes the <maint:impact> element with “full”
or “partial”, where based on #4 above “full” means that the system is
completely offline, and there is the list of <maint:tld> elements signaling
which TLDs are part of the maintenance. If there is a registry system that
supports 10 TLDs and only “.example” is being maintained and will be offline.
This means that the VIP is up but a TLD on the system will be unavailable. The
assumption is that the <maint:impact> element would be set to “full” and there
would be an “example” <maint:tld> element. If the system takes a maintenance
and the VIP is down, then one option is to set the <maint:impact> element to
“full” and include all of the TLDs in the list of <maint:tld> element. One
issue is that the TLDs should only include the TLDs that the client is
authorized to access, so the client would not know whether it’s all of the TLDs
supported by the system. My recommendation to signal that the system is down
is to set the <maint:impact> to “full” and to have no <maint:tlds> element,
which means all TLDs. If the absence of a <maint:tlds> element signals all
TLDs or that the maintenance is at the system-level, then we should revise the
description to be explicit about this. Should there be a new element, such as
an empty <maint:system> element as a choice with the <maint:tlds> element to
explicitly signal a system-level maintenance versus a TLD-level maintenance?
The side effect of not being explicit is that implementers will take different,
inconsistent ways of signaling a system-level maintenance. Adding a
<maint:system> element is most explicit, so that would be my preference.
6. Support for courtesy (e.g., 2 weeks, 1 week, 2 days, 1 day prior to
maintenance) notices and maintenance end notices.
* This change was incorporated into
draft-ietf-regext-epp-registry-maintenance-10.
* There currently exists courtesy notices that provide reminders for a
maintenance and doesn’t reflect a change in the maintenance. There is also an
end maintenance notice that marks that end of the maintenance and doesn’t
reflect a change in the maintenance. The recommendation was to include the
“courtesy” and “end” types to the <maint:pollType> element enumerated list with
the associated descriptions.
The gaps that are open or require additional consideration include gap #3 “Need
for a formatted HTML description”, gap #4 “The impact element values of “full”
and “partial” are a little unclear”, and gap #5 “How to signal the maintenance
of an entire system versus the maintenance of an individual or set of TLDs on
the system”. I include my preferences embedded above.
Thanks,
--
JG
[cid:[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: James Gould <[email protected]>
Date: Thursday, January 7, 2021 at 8:39 AM
To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [regext] WG LAST CALL:
draft-ietf-regext-epp-registry-maintenance-09
Antoin,
I was surprised to see draft-ietf-regext-epp-registry-maintenance move to WGLC
based on the work that has been progressing on the mailing list, so at this
point I can’t support publication of the document. The document editors have
addressed my prior feedback. Upon a fresh review, below is my feedback:
1. Upon the draft passing WGLC, the version should be updated to
“maintenance-1.0”. This change should not happen now.
2. Section 3.3 “Maintenance Elements”
a. I’m taking the action item to see how the existing registrar notices
map to the elements defined in this section. The registrar notices are
free-form currently, but there is some consistency of structure that needs to
be evaluated against the formal structure defined in
draft-ietf-regext-epp-registry-maintenance. I anticipate changes to the
elements in Section 3.3 “Maintenance Elements” coming out of this mapping
exercise.
3. Section 4.1.3 “EPP <info> Command”
a. Nit – Change “either <maint:id>” to “either the <maint:id> child
element” and change “or <maint:list> child element” to “or the <maint:list>
child element”.
4. Section 7 “Security Considerations”
a. It would be worthwhile to consider the security associated with what
maintenance information to return back to the client. A registry access point
may return maintenance information for many top-level domains (or registry
zones), where the client has authorization to access a subset of top-level
domains. My recommendation is to define the considerations that take into
account authorization of the client. For example:
i. “A server MUST only provide maintenance information for clients
that are authorized. If a client queries for a maintenance identifier, per
section 4.1.3.1 “Info Maintenance Item”, that it’s not authorized to access,
the server MUST return an EPP error result code of 2201 [RFC5730]. The list of
top-level domains or registry zones returned in the “Info Maintenance Item”
response SHOULD be filtered based on the top-level domains or registry zones
the client is authorized. Authorization of poll messages is done at the time
of poll message insertion and not at the time of poll message consumption.”
ii. The poll message use case is a corner case, but I believe it’s
important to cover it.
5. Section 9 “References”
a. I believe that draft-ietf-regext-unhandled-namespaces would need to
move into the Normative References since it’s referenced in a normative
sentence.
--
JG
James Gould
Fellow Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 1/4/21, 9:40 AM, "regext on behalf of Antoin Verschuren"
<[email protected] on behalf of [email protected]> wrote:
The following working group document is believed to be ready for submission
to the IESG for publication as a standards track document:
https://secure-web.cisco.com/18eaw5Rc7eRHLW7NT557WL-OEIuRsuRZfA7LKp3BJ8CRDnwUbnkSep_2VLycXzaOvmv49tji_vZXkav_WSa0LDImf7iVSPHuVnheksrC-Z4yjC-TCdX06-Lys-gkODiVilrOZp1WOmoSapmIw9J5pD0-c_UpkQYAeekRFAzwm17KphqdWz9cW1VprZlDOloub5pH3QB11p7XdAbJQOs_f-_NiiPLxZDEVHyLx2QvUBtzvazi50NwL3TPdpF2dVgB7vFSXzLopwYOp3mnMp-e1dw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F
This WG last call will end at close of business, Monday, 18 Januari 2021.
Please review this document and indicate your support (a simple “+1” is
sufficient) or concerns with the publication of this document by replying to
this message on the list.
The document shepherd for this document is James Galvin.
Regards,
Antoin and Jim
_______________________________________________
regext mailing list
[email protected]
https://secure-web.cisco.com/1CE4ls-J9vyi17Z5wA242rs-KkkAsctHnLiGKkA_kgQavoiXTstq55sAh91oQYVV3zS33dzM8y3GY1nYLN4gSGgjfS09ccNXbUlpHFZUgbKtUIvuU45KQpfmOn-jqJA_nGG3Bfz4IRazNKf73lHiol397BADwass3Bi3_isz7AZ066VdhCChq6fGBvIuMmp-d-elI3ur-dS4rOm7bxi21gHhBvucBpJV6ajYIeoANmEpcOT0grGvxyqHJhTTHLr9bUv34eF1HxM1l-LBv3jiguZli7S0kkBSRiHe6IGjd7Hg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
