[regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-03.txt

[Dmitry Belyavsky]

Dear colleagues,

Please see the updated version of the draft.

According to the discussion on the mailing list, the document is
significantly reworked.
Now it relies on the announcement of the EAI support in  and
 elements of the EPP protocol.

-- Forwarded message -
From: 
Date: Mon, Feb 22, 2021 at 10:01 AM
Subject: New Version Notification for draft-belyavskiy-epp-eai-03.txt
To: Dmitry Belyavskiy , James Gould 



A new version of I-D, draft-belyavskiy-epp-eai-03.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:   draft-belyavskiy-epp-eai
Revision:   03
Title:  Use of Internationalized Email Addresses in EPP protocol
Document date:  2021-02-22
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-belyavskiy-epp-eai-03.txt
Status: https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/
Html:
https://www.ietf.org/archive/id/draft-belyavskiy-epp-eai-03.html
Htmlized:   https://tools.ietf.org/html/draft-belyavskiy-epp-eai-03
Diff:
https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-epp-eai-03

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
   appearing 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.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

Re: [regext] Murray Kucherawy's No Objection on draft-ietf-regext-rfc7482bis-02: (with COMMENT)

[Mario Loffredo]

Hi guys,

please find my comments below.

Il 21/02/2021 19:32, Jasdip Singh ha scritto:

Hello Scott,

Please find my comment below.

Jasdip

On 2/18/21, 11:13 AM, "regext on behalf of Hollenbeck, Scott"shollenbeck=40verisign@dmarc.ietf.org>  wrote:


 > -Original Message-
 > From: Murray Kucherawy via Datatracker
 > Sent: Thursday, February 18, 2021 3:30 AM
 > To: The IESG
 > Cc:draft-ietf-regext-rfc7482...@ietf.org;regext-cha...@ietf.org;
 >regext@ietf.org; Mario Loffredo
 > Subject: [EXTERNAL] Murray Kucherawy's No Objection on draft-ietf-regext-
 > rfc7482bis-02: (with COMMENT)
...
 > In Section 4.1:
 >
 >If a server receives a search request but cannot process the request
 >because it does not support a particular style of partial match
 >searching, it SHOULD return an HTTP 422 (Unprocessable Entity)
 >[RFC4918] response.
 >
 > Why's that only a SHOULD?  What else might an implementer choose to do,
 > and why might that be a reasonable thing to do?  Or if there's no good
 > answer to this, maybe that should be a MUST?
 
 [SAH] I'm going to blame that on one of the WEIRDS co-chairs ;) who reviewed 7482.
 
 I agree that it might help to add some more text to explain the rationale for the SHOULD. I don't recall why we used SHOULD here, other than noting that there may be some other response code that might be more appropriate based on a server's policy settings. A server that doesn't support search at all, for example, might instead return a 405 response code. Hmm, might this be an appropriate explanation right here?


[ML] I guess that SHOULD was used instead of MUST because the asterisk 
character is meaningful only for those servers implementing partial 
matching, otherwise it is like any other character. Partial matching is 
optional and REST API providers generally ignores capabilities they 
don't support. For example, unrecognized optional query parameters are 
simply ignored when unsupported.


However, I agree that a server must inform the client that partial 
matching is not allowed just to disambiguate the 404 response received 
when the asterisk character is meaningless from the same response when 
it is meaningful but no results are found.



Best,

Mario


[JS] Since, per Section 1, returning 501 (Not Implemented) is a MUST for any 
unsupported query types (including search), employing 405 (Method Not Allowed) 
for the unsupported-search scenario to help explain the SHOULD for 422 
(Unprocessable Entity) could be confusing. Just wanted to highlight that. :)
 


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


--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

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

Re: [regext] Secdir last call review of draft-ietf-regext-unhandled-namespaces

[Gould, James]

Tiru,


In re-looking at it, it was intended to reference the set of normative EPP 
RFC’s used in the draft, which originally included RFC 5730, 5731, 3915, 5910, 
and 8590.  We moved all of the EPP RFCs 3915, 5910, and 8590 from normative 
references to informational references because they’re only used in the 
examples, which leaves the RFC 5730 and 5731 normative references.  I believe 
that the RFC 5731 normative reference can also be made an informational 
reference, since it’s only used in the examples.  If that was to be done, it 
would only leave RFC 5730, which is the target of the statement in the Security 
Considerations section.  This is a long way of proposing moving RFC 5731 to be 
informational and remove the second sentence “The security considerations 
described in these other specifications apply to this specification as well. “ 
from the Security Considerations section, since the first sentence covers RFC 
5730 and no other EPP RFCs apply.



Thanks,

--

JG

[cid:image001.png@01D7090F.9AA1BF90]

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

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

Verisign.com

From: "Konda, Tirumaleswar Reddy" 
Date: Sunday, February 21, 2021 at 6:48 AM
To: "sec...@ietf.org" , "regext@ietf.org" , 
"draft-ietf-regext-unhandled-namespaces@ietf.org" 

Subject: [EXTERNAL] Secdir last call review of 
draft-ietf-regext-unhandled-namespaces
Resent-From: 
Resent-To: James Gould , , 
, , , 
, , 
, David Smith , David Smith 

Resent-Date: Sunday, February 21, 2021 at 6:48 AM

Reviewer: Tirumaleswar Reddy
Review result: Has nits

This document does not define any new EPP protocol elements, it specifies an 
operational practice using the existing EPP protocol. It does not discuss any 
security aspects other than relying on the security considerations in EPP 
protocol [RFC5730].

The security considerations described in these other specifications apply to 
this specification as well.

Comment> What other specifications are you referring to ?

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

[regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-04.txt

[Dmitry Belyavsky]

New version of the draft uploaded.

Major changes include the more exact email syntax references.

-- Forwarded message -
From: 
Date: Mon, Feb 22, 2021 at 5:40 PM
Subject: New Version Notification for draft-belyavskiy-epp-eai-04.txt
To: Dmitry Belyavskiy , James Gould 



A new version of I-D, draft-belyavskiy-epp-eai-04.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:   draft-belyavskiy-epp-eai
Revision:   04
Title:  Use of Internationalized Email Addresses in EPP protocol
Document date:  2021-02-22
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-belyavskiy-epp-eai-04.txt
Status: https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/
Html:
https://www.ietf.org/archive/id/draft-belyavskiy-epp-eai-04.html
Htmlized:   https://tools.ietf.org/html/draft-belyavskiy-epp-eai-04
Diff:
https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-epp-eai-04

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
   appearing 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.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

[regext] I-D Action: draft-ietf-regext-rfc7482bis-03.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   : Registration Data Access Protocol (RDAP) Query Format
Authors : Scott Hollenbeck
  Andy Newton
Filename: draft-ietf-regext-rfc7482bis-03.txt
Pages   : 26
Date: 2021-02-22

Abstract:
   This document describes uniform patterns to construct HTTP URLs that
   may be used to retrieve registration information from registries
   (including both Regional Internet Registries (RIRs) and Domain Name
   Registries (DNRs)) using "RESTful" web access patterns.  These
   uniform patterns define the query syntax for the Registration Data
   Access Protocol (RDAP).  If approved, this document obsoletes RFC
   7482.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-rfc7482bis-03
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rfc7482bis-03

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.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-rfc7482bis-03.txt

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of internet-
> dra...@ietf.org
> Sent: Monday, February 22, 2021 12:12 PM
> To: i-d-annou...@ietf.org
> Cc: regext@ietf.org
> Subject: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-rfc7482bis-03.txt
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> 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   : Registration Data Access Protocol (RDAP) Query 
> Format
> Authors : Scott Hollenbeck
>   Andy Newton
>   Filename: draft-ietf-regext-rfc7482bis-03.txt
>   Pages   : 26
>   Date: 2021-02-22
>
> Abstract:
>This document describes uniform patterns to construct HTTP URLs that
>may be used to retrieve registration information from registries
>(including both Regional Internet Registries (RIRs) and Domain Name
>Registries (DNRs)) using "RESTful" web access patterns.  These
>uniform patterns define the query syntax for the Registration Data
>Access Protocol (RDAP).  If approved, this document obsoletes RFC
>7482.

[SAH] This version was published at address comments provided by the IESG 
during their review of the document. I believe all the comments (there were no 
DISCUSSes) have been addressed.

Scott

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

[regext] Protocol Action: 'Extensible Provisioning Protocol (EPP) Unhandled Namespaces' to Proposed Standard (draft-ietf-regext-unhandled-namespaces-08.txt)

[The IESG]

The IESG has approved the following document:
- 'Extensible Provisioning Protocol (EPP) Unhandled Namespaces'
  (draft-ietf-regext-unhandled-namespaces-08.txt) as Proposed Standard

This document is the product of the Registration Protocols Extensions Working
Group.

The IESG contact persons are Murray Kucherawy and Barry Leiba.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/




Technical Summary
This document defines an operational practice that enables the server to
return information associated with unhandled namespace URIs that is
compliant with the negotiated services defined in RFC 5730, occasioned
by the handling of certain poll messages.

Working Group Summary
draft-ietf-regext-unhandled-namespaces-06 is on standards track as an
Applicability Statement.  It specifies a way for a server to return
data to a client when the server knows that the data's namespace was not
specified as being supported by the client (via the client's negotiated
login services). The server accomplishes this by embedding the
unhandled-namespace information into  elements in its
responses. Because the server's responses conform to RFC 5730, these
responses will pass any client's strict XML parsing while also delivering
the unhandled-namespace data for the client to consume (or ignore) as it
sees fit.

There remains a difference of opinion on whether the draft will incur
"interoperability problems" with respect to the way RFC5730 describes
 and  elements. Specifically, the concern is whether
clients will neglect to capture the  data returned in an
unhandled-namespaces response due to those clients receiving a "success"
response code when they had expected to look at the  only in
cases of an "error" response code. To address these concerns, the draft
now includes an Implementation Considerations section with guidance for
both clients and servers.

Document Quality
This document has been discussed on the regext mailing list, and its
authors have repeatedly edited the document to address concerns. The
document now includes an "Implementation Considerations" section to
provide specific guidance to both clients and servers to reduce any 
operational impacts of the processes described in the draft.

Personnel
Document shepherd is David Smith
Area Director is Barry Leiba

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

[regext] I-D Action: draft-ietf-regext-simple-registration-reporting-03.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-03.txt
Pages   : 34
Date: 2021-02-22

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 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
   transmission and reception 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-03.html

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.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-02.txt

[Joseph Yee]

Hi Tobias,

Many thanks for your feedback. Please see comments inline


On Tue, Nov 3, 2020 at 8:44 AM Tobias Sattler 
wrote:

> Hi Joseph,
> Hi Jim,
>
> Thanks for updating this draft.
>
> Some thoughts and comments from my side:
>
> General thoughts
> This document is intended to be informational. Therefore, I think it is
> better to avoid the word “standard” in the text. Because it would seem to
> be a de facto standard. I think that someone might be irritated by this
> later.
>
I vaguely recalled that some suggested changing this to BCP.  Can't find it
in the minutes. I keep 'informational' with words 'standard' around for
now. Will update on future revisions depends on which way the draft will go.


>
> Abstract
> I would open it up and write about Registries, Registrars, and Resellers.
>
I add the words 'producer' and 'consumer' next to the term registry
operator and the registrar respectively. Would the intro section be better
for the elaboration?



>
> 1. Introduction
> I would define “the producer” and “the consumer” by using the example
> Registries and Registrars as well as Registrars and Resellers. And
> reference later on only to producer and consumer.
>
But wouldn't registrar be a better understanded term?


>
> 2. Data Element Specification
> I am missing the character encoding. You are mentioning it in section 7. I
> would add a reference in section 2 to 7.
>
Done.


>
> 2.1.11 Registrar
> If you open it up to Resellers, then I would rename it to Consumer.
>
Would expanding the definition be better? I haven't made any changes to it,
want to discuss more on this first.


>
> 2.2.5. Trade
> I would add the field trade here, which is not uncommon in the ccTLD
> world. Just to have it right from the start.
>
Added.  Do you know if some ccTLD operators use a custom EPP command on
trade (to domain object)? Or it's domain update with a new contact object
where the registry operator charges on this specific transaction?


>
> 2.4.1. Registrar_ID
> If you open it up to Resellers, then I would rename it to Consumer_ID
>
Same as Registrar_ID.


>
> 3. Report Definition Specification
> After reading it, it is not 100% clear to me, what the delimiter is and if
> the values should be enclosed with (single or double) quotes.
>
We referenced RFC4180 regarding CSV.  The source mentioned double quotes.


>
> Appendix A. Acknowledgment
> There is a typo in bestpractices.domains. It is bestpractice.domains
> without a “s".
>
Fixed.  thanks.

The next revision will incorporate the changes mentioned above. And would
love to discuss more on items I haven't made changes to.

Best,
Joseph


>
>
> Best,
> Tobias
>
> > On 2. Nov 2020, at 23:21, internet-dra...@ietf.org wrote:
> >
> >
> > 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-02.txt
> >   Pages   : 33
> >   Date: 2020-11-02
> >
> > Abstract:
> >   Domain name registries and registrars 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 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 transmission and reception 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-02.html
> >
> > A diff from the previous version is available at:
> >
> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-simple-registration-reporting-02
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > ___
> > regext mailing list
> > regext@ietf.org
> > https://www.ietf.org/mailman/listinfo/regext
>
> ___
> regext