[regext] Adoption request for draft-regext-brown-epp-ttl
Greetings, As the author of the above document, I'd like to ask the chairs to consider it for adoption by the REGEXT working group. Thanks in advance, Gavin. ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl
This is a formal adoption request for Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values: https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/ Please review this draft to see if you think it is suitable for adoption by REGEXT and comment to this message on the list, clearly stating your view. Optionally indicate if you are willing to contribute text, review text, or be a document shepherd. This Call For Adoption will close on Sunday, 14 May. If there are no objections, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] The REGEXT WG has placed draft-regext-brown-epp-ttl in state "Call For Adoption By WG Issued"
The REGEXT WG has placed draft-regext-brown-epp-ttl in state Call For Adoption By WG Issued (entered by Antoin Verschuren) The document is available at https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl
Total +1 to adopt. Willing to contribute, review, etc. tim On Tue, Apr 25, 2023 at 4:54 PM Antoin Verschuren wrote: > This is a formal adoption request for Extensible Provisioning Protocol > (EPP) mapping for DNS Time-To-Live (TTL) values: > > https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/ > > Please review this draft to see if you think it is suitable for adoption > by REGEXT and comment to this message on the list, clearly stating your > view. > Optionally indicate if you are willing to contribute text, review text, or > be a document shepherd. > > This Call For Adoption will close on Sunday, 14 May. > > If there are no objections, the chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl
On Tue, Apr 25, 2023, at 15:54, Antoin Verschuren wrote: > This is a formal adoption request for Extensible Provisioning Protocol > (EPP) mapping for DNS Time-To-Live (TTL) values: > > https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/ +1 for adoption as no specific reasons not to have this standardized extension (but curious how many registries intend to implement it) Separately, Two (+1) quick points on the content for draft version 4. Section 8.1 uses twice the same XML namespace for both cases. I suspect `:schema:` is missing in the second one. As for TTL values: The highest bound should be instead 2147483647 seconds. This comes from RFC 2181: > The definition of values appropriate to the TTL field in STD 13 is not as clear as it could be, with respect to how many significant bits exist, and whether the value is signed or unsigned. It is hereby specified that a TTL value is an unsigned number, with a minimum value of 0, and a maximum value of 2147483647. That is, a maximum of 2^31 - 1. This is repeated in RFC 8499 (The DNS Terminology RFC), but it does just quote RFC 2181 again on that. Also the standard uses 0 as minimum value, but I may not argue this is better than 1 in the XML schema :-) Alternatively, personally, I would prefer the value to be given as XML type of "duration". This allows to still pass it as seconds for those that prefer that, but also allows to pass it in more human friendly formats such as number of minutes, hours, days, etc. It does make however stating the maximum value possible more complicated I guess, so maybe not worth doing? Also, not sure if a single TTL value for everything is enough. Are we sure that all registries will be fine using the same TTL for both NS/A/ and DS? If I take `.com` right now, NS has 2 days of TTL, where DS only one day. Curious of registries views on that. HTH, -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote: > The document editors have indicated that the following document is > ready for submission to the IESG to be considered for publication as > a Proposed Standard: > > Redacted Fields in the Registration Data Access Protocol (RDAP) Response > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/ > > Please indicate your support or no objection for the publication of > this document by replying to this message on list (a simple “+1” is > sufficient). > > If any working group member has questions regarding the publication > of this document please respond on the list with your concerns by > close of business everywhere, Monday, 1 May 2023. > > If there are no objections the document will be submitted to the > IESG. > > The Document Shepherd for this document is Gustavo Lozano Ibarra. Looks good overall, some minor comments/suggestions. Per previous mail from Pawel and Mario, some of the JSON path expressions are not quite right for entities that have multiple roles. There are some issues with the guidance added to the document to account for this, though, and some further updates in this space that would be useful. (We rely on entities having multiple roles in our server implementation at the moment, for reference, and returning a copy of each entity per role as a workaround is not ideal, particularly when addressing the comments here shouldn't be difficult.) To summarise these issues (mostly along the lines of the comments from Pawel and Mario): - The first example use of prePath has a value of: $.entities[?(@.roles[0]=='administrative')] But all that a client can infer from this path is that all entities with "administrative" as their first role have been removed. Since there are no guarantees around ordering of roles within an entity, this doesn't necessarily mean that all entities with "administrative" as one of their roles have been removed from the resulting object. It would be better to use a more general expression in this example (and the others like it) that captured the intent more clearly. Per earlier mail from Pawel, something like: $.entities[?(@.roles[*]=='administrative')] should do the job, though I wasn't able to determine the syntax that would be acceptable for draft-ietf-jsonpath-base. - Section 5.2 at point 4 has: When an entity has multiple roles, include "redacted" members for each role using the role index. This will result in duplicate "redacted" members, but will enable the client to treat redaction consistently when there is a single role per entity or multiple roles per entity. It's not clear why this advice is present, when compared with e.g. having the redacted members be a mapping from the server's policies. For example, if the policy is that administrative contacts not be returned, then a single "redacted" entry with a prePath like "$.entities[?(@.roles[*]=='administrative')]" clearly conveys that message to the client, and the client will understand that those entities will be removed regardless of any additional roles that they might have. How do multiple redacted members enable the client to treat redaction consistently? - Section 5.2 at point 5 has: When there are multiple entities with the same role, include "redacted" members for each entity using the entity index instead of the role. A JSONPath can be created that identifies the entity based on an index of a role selector nodelist, such as "$.entities[?(@.roles[0]=='technical')][0]" for the first entity with the "technical" role. Using the entity index, such as "$.entities[1]", is simpler and recommended. Similarly to the previous point, removing by index obscures the server's intent. To use the example given above, if the server's policy is that the first entity with a technical role is omitted, then the first expression (though with 'roles[*]' instead of 'roles[0]') conveys that message more clearly than removal by way of index. (If the server's behaviour can't be conveyed by way of a JSON path, e.g. where an entity is omitted because they have opted out of being included in responses, then simply omitting the prePath and relying on a specific registered redacted name for the behaviour would make things clearer for the client than presenting an entity index that they can't resolve/use.) - Section 5.1 at point 1 has: When the server is using the Redaction By Removal Method (Section 3.1) or the Redaction by Replacement Value Method (Section 3.4) with an alternate field value, the JSONPath expression of the "prePath" member will not resolve successfully with the redacted response. The client can first key off the "name" member for display logic
Re: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl
+1 to adopt it Best, Tobias > On 25. Apr 2023, at 22:54, Antoin Verschuren > wrote: > > This is a formal adoption request for Extensible Provisioning Protocol (EPP) > mapping for DNS Time-To-Live (TTL) values: > > https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/ > > Please review this draft to see if you think it is suitable for adoption by > REGEXT and comment to this message on the list, clearly stating your view. > Optionally indicate if you are willing to contribute text, review text, or be > a document shepherd. > > This Call For Adoption will close on Sunday, 14 May. > > If there are no objections, the chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
