Re: [regext] [I18ndir] [Last-Call] Genart last call review of draft-ietf-regext-epp-eai-10

[Martin J . Dürst]

Hello John, others,

Many thanks for the comments below. My comment was not intending to stop 
the progress of the draft in question.


Regards,   Martin.

On 2022-06-08 00:50, John C Klensin wrote:

Martin,

Further trimming addresses that I know are on the i18ndir and
draft-ietf-regext-epp-eai.al lists.  Procedurally, dropping the
last-call list may be an issue because, unless the authors or
the REGEXT WG withdraw this document for further consideration,
it will go into IESG review on Thursday.  Then, unless the ART
ADs delay or withdraw it at that time (copying them), the IESG
will normally conduct its review based only on what was said on
the Last Call list (or in notes directly to them).

If I correctly understand what you are suggesting, I agree
although, for some senders, creating an alternate account as you
suggest  might raise some other issues and I have not thought
through the implications for replies.  It also suggests
something that the EAI WG did not consider, which would be to
create an "Alternate-AllASCII-ReplyAddress" header (with a
better and shorter name). I have no idea why it did not come up
-- hindsight is wonderful.  The spec would be rather easy to
write if there were any hope that MUA authors would adopt it.

However, I cannot see any way in which either your suggestion or
that alternate header field one would have any impact on
draft-ietf-regext-epp-eai-11, even if they came to be widely
used.  The I-D is, at least AFAICT, about one thing and one
thing only: a registrar taking information in its database
(presumably via a domain application that came to it) and
transferring it to a registry that then, presumably, puts the
information in its database.  The format and handling of the
registrar database are clearly not an IETF problem.  The authors
and I apparently disagree about whether the registry database
and its usability are issues with which the IETF should be
concerned.  But what a prospective mail sender with a non-ASCII
address might choose to include in outgoing mail is, I think,
rather far out of scope.

best,
john


--On Tuesday, June 7, 2022 17:19 +0900 "Martin J. Dürst"
 wrote:


Sorry to again be late with my comments (and deleting
last-c...@ietf.org and gen-art@ietf from the cc list because I
think that my comment may be a bit premature for them).

I think John below certainly has a point. But with respect to
reachability of non-ASCII containing email addresses (SMTPUTF8
email addresses), it occurs to me that we might sooner or
later be at a point where a prospective sender doesn't have an
SMTPUTF8 capable account, but can nevertheless reach an
SMTPUTF8 email address. The way this is done is simple,
although a bit tedious: The sender just creates an
SMTPUTF8-capable email address account (I seem to remember
that gmail or hotmail may work, although I'm not completely
sure about this). The mail address gets copied into the 'To'
field, and the mail gets sent and reaches the destination. The
reply also should work. Of course, the sender has to check
this separate account for answers on a regular basis.

So it may be true that SMTPUTF8 addresses are not reachable
from every email provider. But it may not be true that
SMTPUTF8 addresses are not reachable from every user. Of
course, there's also the question of readability of an
address, but assuming the address is clearly displayed and can
be easily copied, it doesn't actually have to be readable by
the sender.

Regards,   Martin.

On 2022-06-02 16:05, John C Klensin wrote:

Pete and James,

Let me add one thing to Pete's (and Yoshiro Yoneya's)
comments/concerns.  I tried to raise this earlier, but
obviously did not explain it well:


--On Wednesday, June 1, 2022 20:23 + "Gould, James"
 wrote:


Pete,

Thanks for the review and feedback.  My responses are
embedded below prefixed with "JG - ".
...
On 6/1/22, 1:14 PM, "Pete Resnick via Datatracker"
 wrote:
...
  Reviewer: Pete Resnick
  Review result: On the Right Track

...
  Document: draft-ietf-regext-epp-eai-10
  Reviewer: Pete Resnick
  Review Date: 2022-06-01
  IETF LC End Date: 2022-06-09
  IESG Telechat date: Not scheduled for a telechat

  Summary:

  I think this proposal is reasonable, but I don't think
enough explanation has been given regarding the case
where one side supports the protocol but the other side
doesn't.


Unless I don't understand the use cases for the information
being handled by EPP and this proposed extension, there are
actually three "sides" / "parties" for the data and their use.
One is the registrar or equivalent, in software normally the
EPP client.  The second is the registry or equivalent, in
software normally the EPP server.  If those were the only two
actors, one could be quite relaxed about the server being
ready to handle non-ASCII email addresses because the
decision to accept non-ASCII email addresses or not could be
a contractual matter.

 From a contractual perspective, a registrar/c

Re: [regext] I18ndir early review of draft-ietf-regext-epp-eai-10

[Gould, James]

Yoshiro, 

Thank you for the review and feedback.  I include a response to your minor 
issue embedded below.

-- 
 
JG



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

On 6/1/22, 9:04 PM, "Yoshiro Yoneya via Datatracker"  wrote:

Reviewer: Yoshiro Yoneya
Review result: Ready with Issues

Summary:

  This draft is in good shape regarding protocol.  Regarding to operation,
  having an additional guidance for registrar transfer from EAI supporting
  registrar to non EAI supporting registrar would be better.

Major issues:

  None.

Minor issues:

  When a registrant who has only EAI contact addresses attempts to transfer 
a
  domain from EAI supporting registrar to another non EAI supporting 
registrar,
  then transfer of contact information will cause failure.  If there were
  additional operational guidance addressing this issue in this draft will 
be
  helpful for registrar operators.  For example, when loosing registrar who 
is
  supporting EAI received a transfer request, it should check whether the
  registrant has only EAI contact addresses, and if it was true, the 
registrar
  should advice the registrant to provide alternative ASCII contact 
addresses
  in advance for the successful transfer.

Technically a transfer of the domain name doesn't include a transfer of the 
contact information, where the gaining registrar can create a new contact to 
link to the domain name once the domain name transfer completes.  Transfers of 
a contact in EPP is rarely done, but it is supported in EPP RFC 5733.  In 
section 5.3.2 of the draft, we cover the obligations of the client and the 
server when the opposite party doesn't support EAI.  For the case of a non EAI 
supporting registrar that wants to transfer the contact object via EPP RFC 
5733, there is nothing that will cause an error in the transfer process.  Post 
the transfer, when the non EAI supporting registrar executes a contact info 
command, the EAI supporting server will return the 2308 "Data management policy 
violation" error response, per section 5.3.2 of the draft.  Most likely this 
will result in the non EAI supporting registrar reaching out to the registry 
out-of-band, with the error being mitigated by the registrar supporting EAI or 
the registrar updating the email property of the contact with an ASCII email, 
which will be allowed.  The obligations outlined in section 5.3.2 of the draft 
ensures that EAI addresses are not passed with a non-supporting party at the 
protocol level.   

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

[regext] I-D Action: draft-ietf-regext-epp-eai-12.txt

[internet-drafts]

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   : Use of Internationalized Email Addresses in the 
Extensible Provisioning Protocol (EPP)
Authors : Dmitry Belyavskiy
  James Gould
Filename: draft-ietf-regext-epp-eai-12.txt
Pages   : 13
Date: 2022-06-08

Abstract:
   This document describes an EPP extension that permits usage of
   Internationalized Email Addresses in the EPP protocol and specifies
   the terms when it can be used by EPP clients and servers.  The
   Extensible Provisioning Protocol (EPP), being developed before the
   standards for Internationalized Email Addresses (EAI), does not
   support such email addresses.

   TO BE REMOVED on turning to RFC: The document is edited in the
   dedicated github repo (https://github.com/beldmit/eppeai).  Please
   send your submissions via GitHub.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-epp-eai-12.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-12


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

[regext] Fwd: I-D Action: draft-ietf-regext-epp-eai-12.txt

[Dmitry Belyavsky]

Dear colleagues,

A recent version of the draft is uploaded.

Changes: XML schema registration request is removed.

-- Forwarded message -
From: 
Date: Wed, Jun 8, 2022 at 8:49 PM
Subject: [regext] I-D Action: draft-ietf-regext-epp-eai-12.txt
To: 
Cc: 



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   : Use of Internationalized Email Addresses in the
Extensible Provisioning Protocol (EPP)
Authors : Dmitry Belyavskiy
  James Gould
Filename: draft-ietf-regext-epp-eai-12.txt
Pages   : 13
Date: 2022-06-08

Abstract:
   This document describes an EPP extension that permits usage of
   Internationalized Email Addresses in the EPP protocol and specifies
   the terms when it can be used by EPP clients and servers.  The
   Extensible Provisioning Protocol (EPP), being developed before the
   standards for Internationalized Email Addresses (EAI), does not
   support such email addresses.

   TO BE REMOVED on turning to RFC: The document is edited in the
   dedicated github repo (https://github.com/beldmit/eppeai).  Please
   send your submissions via GitHub.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-epp-eai-12.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-12


Internet-Drafts are also available by rsync at rsync.ietf.org:
:internet-drafts


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


-- 
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [I18ndir] I18ndir early review of draft-ietf-regext-epp-eai-10

[John Levine]

It appears that Gould, James  said:
>Technically a transfer of the domain name doesn't include a transfer of the 
>contact information, where the gaining registrar
>can create a new contact to link to the domain name once the domain name 
>transfer completes.  Transfers of a contact in EPP
>is rarely done, but it is supported in EPP RFC 5733. ...

I agree that most of the time when people transfer domains, they enter new 
contact info at the new registrar.

A more practical issue is that the new registrar generally sends
e-mail to the old owner to notify them or in some cases to ask for
confirmation. If the old registrar handles EAI addresses and the new
one doesn't, that's likely to fail, but I also don't think it's our
problem to solve here.

R's,
John

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

[regext] I-D Action: draft-ietf-regext-simple-registration-reporting-07.txt

[internet-drafts]

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   : Simple Registration Reporting
Authors : Joseph Yee
  James Galvin
Filename: draft-ietf-regext-simple-registration-reporting-07.txt
Pages   : 35
Date: 2022-06-08

Abstract:
   Domain name registries (the producer) and registrars (the consumer)
   report to each other by sharing bulk information through files.  This
   document creates two IANA registries to establish a standard
   reporting mechanism between domain name registries and registrars.
   The first IANA registry lists standard data elements and their syntax
   for inclusion in the files.  The second IANA registry lists standard
   reports based on the standard data elements.  Each report is a file
   formatted as a CSV file.  The advantage of this reporting mechanism
   is that a report, each file, can be imported by recipients without
   any prior knowledge of their contents, although reporting is enhanced
   with a minimum of knowledge about the files.  The mechanism for the
   distribution of and access of the files is a matter of local policy.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-simple-registration-reporting-07.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-simple-registration-reporting-07


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-06.txt

[Joseph Yee]

Hi Jim and all,

Please see my comment inline. The -07 should come out shortly or out
already.

On Fri, Mar 25, 2022 at 10:44 AM Gould, James  wrote:

> Hi,
>
>
>
> I did a detailed review of
> draft-ietf-regext-simple-registration-reporting-06 and below is my feedback:
>
>
>
>1. Introduction
>   1. I’m not sure whether there have been “a number of best practice
>   reports that have evolved”, but I do agree that there have been “a 
> number
>   of best practices that have evolved”.
>
> updated


>
>1.
>   1.
>   2. Nit – “data element aforementioned data element registry” to
>   “data element registry”.
>
> updated


>
>1.
>   1.
>2. Data Element Specification
>   1. Nit – “printed report” could simply be “report”.  I don’t
>   believe printed is relevant.
>
> updated


>
>1.
>   1.
>   2. There is no definition of the format used for the data element
>   names (e.g., upper case, lower case, camel case, snake case).  The names
>   are inconsistent, but they primarily support the use of upper-case 
> leading
>   words, with the use of underbars as a word separator.  My 
> recommendation is
>   to formally define the expected data element names and ensure that all 
> the
>   data element names follow the defined format.
>
> Added text about naming convention.


>
>1.
>   1.
>   2. Overall
>  1. We need to ensure that only elements that are standard
>  elements (non-proprietary) are pre-defined.
>  2. We need to ensure to use a consistent naming convention.
>  3. We need to look to support a candidate list of registration
>  elements that are in line with the elements defined and the naming
>  conventions used in the relevant EPP RFCs.
>
> Agree as a general guideline, and *may* make exceptions on a case by
case basis.


>
>1.
>   1.
>  1.
>   2. General Data Elements
>   1. Transaction_Type
>  1. How do you deal with extensions to the commands outlined in
>  RFC 5730, such as the restore request, restore response, or 
> operations that
>  are not defined in RFC 5730, such as auto renew?
>
> [seeking more input] I intend to add the following paragraph under
'Transaction Type'.  Would love to hear more feedback before adding it.
"Well known and important transactions like restore where it was documented
inside EPP extension, and auto renew invoked by the registry system that
alter the domain's status are allowed."


>
>1.
>   1.
>  1.
>   2. Object_Type
>  1. Since EPP extension can define a new object, then the
>  Object_Type also needs to be extensible, such as the definition of 
> an Email
>  Forwarding, Defensive Registration, or NameWatch objects for .NAME.
>
> This seems to be getting into proprietary objects, or additional
information to the domain object, imo.


>
>1.
>   1.
>  1.
>   2. DateTime
>  1. Shouldn’t this be Date_Time to be consistent with the format
>  of the other data elements?
>
> updated


>
>1.
>   1.
>  1.
>   2. Term
>  1. Why not use Period instead of Term to be consistent with the
>  element used in EPP?
>
> Changed to 'Period', and the old Period (meant for unit) changed to
'Period_Unit'


>
>1.
>   1.
>  1.
>   2. Fee
>  1. I would reference the use of “decimal” for the format, since
>  referencing “balanceType” is unrelated to representing a fee.  The
>  “balanceType” is a decimal value to support a positive (fee) or 
> negative
>  (credit) value, so referencing “decimal” is best.
>
> I believe that balanceType is based on decimals.  I have not reviewed this
one fully.  Will revise after further review.


>
>1.
>   1.
>  1.
>   2. Status
>  1. A status is an individual value.  How do you handle a report
>  that has more than one status?  Does that mean adding multiple rows 
> to the
>  report, each with a different status value?  How do you handle 
> representing
>  additional statuses, such as the RGP statuses?
>  2. My recommendation is to add a Statuses element that supports
>  a list of statuses that is an encoded element in double quotes, such 
> as
>  “clientUpdateProhibited,clientRenewProhibited”.
>
> Added text about multiple values, separated by comma, and enclosed them in
double quote as specified in RFC4180 (about csv)


>
>1.
>   1.
>  1.
>   2. Registrar
>  1. There is the chance that the free-form registrar name could
>  include the delimiter, so the use of quoting will be needed.
>
> Added text about possible of having a comma in the string, and enclosed
them in double quote as specified in RFC4180 (about csv) if needed

>
>1.
>   1.
>  1.
>   2. Period
>  1. Why not call