[regext] Comments on draft-lozano-ietf-eppext-registrar-expiration-date-01

[Patrick Mevzek]

Hello Gustavo,

I'm implemented
draft-lozano-ietf-eppext-registrar-expiration-date-01
in my opensource EPP client.

I have the following comments:

- first, would it be possible to switch the document name from eppext
  to regext? It would be easier to track it since for now, it does not
appear on https://datatracker.ietf.org/wg/regext/documents/ 
(or if it is possible for this page to also track *-eppext-* I-Ds ?)

- for the new attribute, "flag" does not seem a very descriptive name.
  Maybe "sync" instead ?
Related to that you've added another layer in the XML structure just
to convey this new flag, but then it creates 4 cases depending on the
presence or absence of the exDate node below. Shouldn't it be simpler
with just a node with a mandatory attribute and an optional (date)
value?

- since you use the same structure for client commands and server
  replies, the text in §2.1 does not explain what the server
could/should reply, as it is written only from the registrar
perspective. Could you elaborate which specific cases the server might
use?

- there are no examples of the third case of §2.1, that is flag=0 + no
  exDate node. Could you add one?

HTH,

-- 
Patrick Mevzek
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.  -- George Bernard Shaw

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-rdap-status-mapping

[Gustavo Lozano]

I agree with Scott¹s comments.

I agree with Jim Galvin¹s suggestion that this draft should be standards
track.

After these changes, I think that the draft should be ready for
publication as an RFC.

It's worth mentioning that this draft is important for the RDAP deployment
efforts in the gTLD space.

Regards,
Gustavo



On 6/17/16, 06:50, "regext on behalf of Hollenbeck, Scott"
 wrote:

>Two comments:
>
>1. The IANA Considerations section includes requests to register a number
>of RDAP status values. The registrant for each of these values is
>"VeriSign Inc.". Given that the intended status of this document is
>currently "Informational" that might be OK, but since these values aren't
>proprietary to Verisign I'm going to suggest that it might be more
>appropriate for the IESG to be the registrant.
>
>OLD:
>Registrant Name: VeriSign Inc.
>Registrant Contact Information: epp-regis...@verisign.com
>
>NEW:
>Registrant Name: IESG
>Registrant Contact Information: i...@ietf.org
>
>2. The Security Considerations section says "The mapping described in
>this document do not provide any security services beyond those described
>by RDAP [RFC7483]". That's true, but I think some text needs to be added
>to note that implementation of this mapping can expose more information
>about registered domain names to any client who asks, and that raises
>privacy concerns. The issue should be noted, and the possible mitigation
>using client authentication with authorization and access control
>policies can be described.
>
>Scott
>
>___
>regext mailing list
>regext@ietf.org
>https://www.ietf.org/mailman/listinfo/regext


smime.p7s
Description: S/MIME cryptographic signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext