Re: [regext] Erik Kline's Discuss on draft-ietf-regext-rdap-partial-response-13: (with DISCUSS)
On Sun, Sep 6, 2020 at 5:42 AM Mario Loffredo wrote: > Hi Erik, > > thanks a lot for your review. Plase find my comments inline. > > Il 05/09/2020 23:22, Erik Kline via Datatracker ha scritto: > > Erik Kline has entered the following ballot position for > > draft-ietf-regext-rdap-partial-response-13: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/ > > > > > > > > -- > > DISCUSS: > > -- > > > > Probably I'm just not properly aware of details in the referenced RFCs, > but > > I had a few questions that came to mind. > > > > [ section 2 ] > > > > * How are multiple keys encoded in a fieldSet parameter value? An > example > >would be welcome. > [ML] In my opinion this case is considered among the unsupported > fieldSet values producing a Bad Request response code as stated in > section 5. > > > > * What should be done with a query containing an empty fieldSet? > >E.g. ...?...&foo=bar&fieldSet=&baaz=quux > [ML} This case is considered in section 5 too. > Ah, yes, thank you. > > [ section 2.1 ] > > > > * How much data transfer is actually saved if servers are supposed to > send > >these subsetting_metadata structures in every response? Are we just > >swapping data bytes transferred for meta-data bytes transfered? > > [ML] Not all the responses. Just the responses to search queries which > are those returning an array of results. > Ah, I see, yes a more awake and attentive reading of: Therefore, servers implementing the query parameter described in this specification SHOULD provide additional information in their responses about the available field sets. makes sense. Thank you. That clears it all up for me. In general, in those responses, the payload due to the metadata > information is considerably lower than the payload due to the array of > results. > > It wouldn't make sense to provide the subsetting_metadata object as part > of a lookup response just because, in this case, the sizes of metadata > and relevant information would be comparable. > > > Best, > > Mario > > > > > > > > > > > > -- > Dr. Mario Loffredo > Systems and Technological Development Unit > Institute of Informatics and Telematics (IIT) > National Research Council (CNR) > via G. Moruzzi 1, I-56124 PISA, Italy > Phone: +39.0503153497 > Mobile: +39.3462122240 > Web: http://www.iit.cnr.it/mario.loffredo > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Erik Kline's No Objection on draft-ietf-regext-unhandled-namespaces-07: (with COMMENT)
No particular text recommendations from me; this seems fine. I was just observing a phrase fragment that seemed to be either ungrammatical or not easy to parse. The intent of the text was, and is, clear though. On Wed, Feb 17, 2021 at 5:50 AM Gould, James wrote: > > Erik, > > In considering your comment: > > * "does not define new protocol" -> "does not define a new protocol", > Perhaps > > The intent is to indicate that no new EPP protocol elements are defined. How > about changing it to "does not define new EPP protocol elements"? This would > be included in the posting of draft-ietf-regext-unhandled-namespaces-08 along > with addressing the other feedback. > > Thanks, > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 2/17/21, 1:03 AM, "Erik Kline via Datatracker" wrote: > > > Erik Kline has entered the following ballot position for > draft-ietf-regext-unhandled-namespaces-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://secure-web.cisco.com/1EvzkPla5kphOxGVrCWpPS-vQ-Lm067uGD8F4DXzkVahpMJxVLLNs_-Okm_Ik_CTvBNgJoT-07wBTP_Fy6Gb9hOK_l6LDjmTe-zXsSs-o9sODDOeCHT8h_gEU4VOQnLzPyw7l7KgyQAI-uJRyPJnGYzNkWZMPIa6yI_x7q3beroMTMZJekZJz627YN1XJKgtC3A5VoC_gnuwma7Xsp25JJs0RsB1c1lTK2ORGpi6fv9hE7T40WHXiVOukDEqicdWA/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://secure-web.cisco.com/1DObBfVwLMA9UQQeYSf2Ee-qWbljZcJZ0rWT1j6mlVZkOwB16KNnSyHTDa8k5iafiIBIbdUaUNsia_qWS9U5Yp0XK9igtqn7evXh9YRW__gCkdEu8opXvs_6gXrx1MTPgubXXQ53ZZUFr-JDX0zCWRkGjs1ox9lOzdMoNdgai0L9wo1MfAJmtZgsclohTVFrzJF_2CRzDjFmjp6309c2OfXgQTZBrsVpTyTlxFkU5MZjYsabZkSkBWfO6y5PY0fgm/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-unhandled-namespaces%2F > > > > -- > COMMENT: > -- > > [[ nits ]] > > [ section 4 ] > > * "does not define new protocol" -> "does not define a new protocol", > perhaps > > > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Erik Kline's No Objection on draft-ietf-regext-rfc7483bis-04: (with COMMENT)
> > [ section 4.5 ] > > > > * Is there a formal constraint on the format of string values of > > "eventDate"? If so, is it called out somewhere? > > > > All the examples are of a very obvious, specific format...but is that > > required? > > [SAH] The required syntax for date and time values is described in Section 3: > "The syntax for values denoting dates and times is defined in [RFC3339]" Ack; thanks. ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Erik Kline's No Objection on draft-ietf-regext-epp-registry-maintenance-17: (with COMMENT)
Tobias,
I took a look at the changes in github; LGTM.
Thanks!
On Tue, Sep 28, 2021 at 10:29 AM Tobias Sattler
wrote:
> Hi Erik,
>
> Thank you for your feedback!
>
> We have addressed both raised issues (please see inline) and updated our
> GitHub repository (
> https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt).
> Hope that is fine for you.
>
> We will do the update along with the other changes raised when we are
> asked to do the update.
>
> Best,
> Tobias
>
> > On 25. Sep 2021, at 01:01, Erik Kline via Datatracker
> wrote:
> >
> > Erik Kline has entered the following ballot position for
> > draft-ietf-regext-epp-registry-maintenance-17: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/blog/handling-iesg-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> >
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > [S3.3, nit]
> >
> > * Seems like the text could be phrased in terms of
> > expectations for the impact, i.e.
> >
> > "If access is expected to be {intermittently unavailable,
> >completely unavailable,
> >unaffected}, ..."
> >
> >
> > (give that things can go from "none" to "full" unexpectedly =).
>
> TS: We changed the wording.
>
> >
> > [S3.3, question]
> >
> > * For the type attribute values, the meanings of
> > most are immediately obvious to me except for "ote". Assuming this
> > means "Operational Test and Evaluation", or something similar,
> > perhaps expand/explain this?
> >
> > ("ote" does not appear in the RFC Editor's list of abbreviations.)
> >
> >
>
> TS: Yes, ote stands for "Operational Test and Evaluation”. We added a
> clarification under S1.1.
>
> >
> > ___
> > 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
[regext] Erik Kline's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-regext-dnrd-objects-mapping-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/ -- COMMENT: -- [ section 4.5 ] * For text representations you want RFC 5952 rather than 4291. [ section 5.1.2.1.5, 5.2.2.1.3 ] * It's not clear that ",v4" or ",v6" are adding anything. The IP address family should be unambiguous without the hint. No change necessary, it just seems like this isn't really needed. (For example, if there's even a remote possibility someone might try to list IPv4-mapped IPv6 addresses -- or even worse, compat addresses -- then there are going some other, much bigger problems ahead.) [ section 5.4.1.1 ] * Is it recommended at all that rdeRegistrar:url be https whenever possible? * In addition to whois name/url should there RDAP information? Or is the http/https whois URL expected to handle RDAP? ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Erik Kline's Discuss on draft-ietf-regext-rdap-partial-response-13: (with DISCUSS)
Erik Kline has entered the following ballot position for draft-ietf-regext-rdap-partial-response-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/ -- DISCUSS: -- Probably I'm just not properly aware of details in the referenced RFCs, but I had a few questions that came to mind. [ section 2 ] * How are multiple keys encoded in a fieldSet parameter value? An example would be welcome. * What should be done with a query containing an empty fieldSet? E.g. ...?...&foo=bar&fieldSet=&baaz=quux [ section 2.1 ] * How much data transfer is actually saved if servers are supposed to send these subsetting_metadata structures in every response? Are we just swapping data bytes transferred for meta-data bytes transfered? ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Erik Kline's No Objection on draft-ietf-regext-rdap-sorting-and-paging-17: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-regext-rdap-sorting-and-paging-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/ -- COMMENT: -- [[ comments ]] [ section 2.3 ] * My current understanding is that it's not possible to request a sort by IP address in general (i.e. without regard to IP address family). Otherwise, since some IPv6 addresses (admittedly not any within the current 2000::/3 GUA space) might be numerically less then some IPv4 addresses, I think there would probably need to be some text around relative ordering between IPv4 and IPv6 addresses regardless of numerical equivalent values. But again: my reading is that sort can only be by ipV4 or ipV6 (and not just some generalized "ip" parameter), so this shouldn't be necessary. [[ nits ]] [ section 2.1 ] * s/value of sort "parameter"/value of the "sort" parameter/ perhaps? [ section 2.4 ] * I think the cursor value "b2Zmc2V0PTEwMCxsaW1pdD01MAo=" might decode to 'offset=100,limit=50\n' (with a trailing newline). The base64 encoding without the trailing newline might be 'b2Zmc2V0PTEwMCxsaW1pdD01MA==', but someone should double-check me on that. ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Erik Kline's No Objection on draft-ietf-regext-rfc7483bis-04: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-regext-rfc7483bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/ -- COMMENT: -- [[ comments ]] [ section 5.4 ] * It seems a shame that the startAddress/endAddress keys are used with IPv6 prefixes. I do wish there could be some cidrBlock key instead. Oh well. [[ questions ]] [ section 4.5 ] * Is there a formal constraint on the format of string values of "eventDate"? If so, is it called out somewhere? All the examples are of a very obvious, specific format...but is that required? ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Erik Kline's No Objection on draft-ietf-regext-unhandled-namespaces-07: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-regext-unhandled-namespaces-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/ -- COMMENT: -- [[ nits ]] [ section 4 ] * "does not define new protocol" -> "does not define a new protocol", perhaps ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Erik Kline's No Objection on draft-ietf-regext-epp-registry-maintenance-17: (with COMMENT)
Erik Kline has entered the following ballot position for
draft-ietf-regext-epp-registry-maintenance-17: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/
--
COMMENT:
--
[S3.3, nit]
* Seems like the text could be phrased in terms of
expectations for the impact, i.e.
"If access is expected to be {intermittently unavailable,
completely unavailable,
unaffected}, ..."
(give that things can go from "none" to "full" unexpectedly =).
[S3.3, question]
* For the type attribute values, the meanings of
most are immediately obvious to me except for "ote". Assuming this
means "Operational Test and Evaluation", or something similar,
perhaps expand/explain this?
("ote" does not appear in the RFC Editor's list of abbreviations.)
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
[regext] Erik Kline's No Objection on draft-ietf-regext-rfc7484bis-04: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-regext-rfc7484bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/ -- COMMENT: -- [S5.2 & 13.2, comment] * It's probably better to refer to RFC 5952 for IPv6 text representations. (If not, why not?) [S5.3, comment] * It might be good to place additional restrictions on the ordering of AS numbers in the range syntax to require increasing order, ["101-202"], and not allow ["202-101"]. ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Erik Kline's Yes on draft-ietf-regext-epp-ttl-17: (with COMMENT)
Erik Kline has entered the following ballot position for
draft-ietf-regext-epp-ttl-17: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
--
COMMENT:
--
# Internet AD comments for draft-ietf-regext-epp-ttl-17
CC @ekline
* comment syntax:
- https://github.com/mnot/ietf-comments/blob/main/format.md
* "Handling Ballot Positions":
- https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
## Nits
### S1.2.2.1, S1.2.2.2, S1.2.2.4
* Should the closing tag be ""?
### S2.1.1.1, S2.1.1.2, S2.2.1
* Unless EPP has standardized not following RFC 5952 S4.3, the IPv6 address
should be lower-cased ("2001:db8::8:800:200c:417a").
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
