[regext] Fw: New Version Notification for draft-yao-regext-epp-quic-01.txt
Dear all, A new version of draft has been submitted for Extensible Provisioning Protocol (EPP) Transport over QUIC. In this vesion, Has been made fully compliant with RFC 5730 Aligns with the structure and makeup of EPP over TCP (EoT) in RFC 5734 Fully pluggable transport for EPP with EoT Verisign Dan Keathley and James Gould added as co-authors If there are some time slots left in the IETF 119 meeting, we would apply 10 minutes slot. We (me, Dan and James) plan to give an introduction about this draft. Any comments about this draft are welcome. Thanks a lot. Jiankang Yao From: internet-drafts Date: 2024-02-18 16:38 To: Dan Keathley; Daniel Keathley; Hongtao Li; James Gould; Jiankang Yao; Man Zhang Subject: New Version Notification for draft-yao-regext-epp-quic-01.txt A new version of Internet-Draft draft-yao-regext-epp-quic-01.txt has been successfully submitted by Jiankang Yao and posted to the IETF repository. Name: draft-yao-regext-epp-quic Revision: 01 Title:Extensible Provisioning Protocol (EPP) Transport over QUIC Date: 2024-02-18 Group:Individual Submission Pages:10 URL: https://www.ietf.org/archive/id/draft-yao-regext-epp-quic-01.txt Status: https://datatracker.ietf.org/doc/draft-yao-regext-epp-quic/ HTMLized: https://datatracker.ietf.org/doc/html/draft-yao-regext-epp-quic Diff: https://author-tools.ietf.org/iddiff?url2=draft-yao-regext-epp-quic-01 Abstract: This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a QUIC connection. EPP over QUIC (EoQ) leverages the performance and security features of the QUIC protocol as an EPP transport. The IETF Secretariat ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01
Hello all, I agree with Tim's point. Support +1 RFC8499 provides the DNS terminology, which provides a list of DNS protocol related terminology. This document can provide a neutral DNS Data Dictionary related to Domain name registered data. I think that it will be useful for registry, registrar and registrant. One suggestion: RFC8499 is named with "DNS terminology" while this document is named with "DNS Data Dictionary". Just having a quick look at these two names, it seems it is not easy to distinguish between them. How about renaming "DNS Data Dictionary" to "DNS Registration Data Dictionary" or seome else? Best Regard. Jiankang Yao From: Tim Wicinski Date: 2021-12-19 10:36 To: regext Subject: Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01 REGEXT chairs Please count this as my +1 for adopting this work. I find this highly relevant to not just create this dictionary, but offer precise definitions for terms to avoid any "squishness" which seems to come back to bite up when we least expect it. The work in DNSOP on DNS Terminology is a good example of doing something a little dull provides benefits elsewhere. Tim On Sat, Dec 18, 2021 at 9:39 AM Steve Crocker wrote: We request the REGEXT WG adopt draft-flanagan-regext-datadictionary-01 as a work item. The goal is to establish a IANA registry of data elements that are commonly used in multiple applications that handle registration data. We anticipate this dictionary will be overseen by an IESG-appointed set of experts. The existence of this dictionary will not impose any requirements that all of these data elements will be collected nor that any particular set of these will be made available in response to requests. Rather, the intent here is simply to provide a common list of possible data elements and a publicly visible set of names for the data elements. We expect there will be additions to the dictionary, so the list of data elements in the current draft is most likely not complete. That said, we feel it is useful to move forward with the review and adoption process. If and when other data elements are proposed, they can be included through the usual process. Thank you, Heather Flanagan Steve Crocker Edgemoor Research Institute ___ 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-belyavskiy-epp-eai
+1 Jiankang Yao From: Tobias Sattler Date: 2021-03-16 22:59 To: Mario Loffredo CC: Antoin Verschuren; regext Subject: Re: [regext] CALL FOR ADOPTION: draft-belyavskiy-epp-eai +1 Tobias > On 16. Mar 2021, at 15:18, Mario Loffredo wrote: > > I support adoption. > > Best, > > Mario > > Il 15/03/2021 14:19, Antoin Verschuren ha scritto: >> This is a formal adoption request for “Use of Internationalized Email >> Addresses in EPP protocol”: >> >> https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/ >> >> Please review this draft to see if you think it is suitable for adoption by >> REGEXT, and comment to the list, clearly stating your view. >> >> Please indicate if you are willing to contribute text, review text, or be a >> document shepherd. >> >> Please also indicate any preference you have for a proposed milestone date. >> >> This call for adoption ends Monday, 29 March 2021. >> >> If there are no objections, and we receive enough consensus for adoption, >> 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 > > -- > 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 ___ 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] Internationalized Email Addresses and EPP
Hello all,
Otion 1 is ideal and option 2 are reasonable.
Since not many registries and registrars support EAI services and few
registrants use EAI address in the near future, I think that option 2 might be
the current direction.
Best Regards
Jiankang Yao
From: Barry Leiba
Date: 2020-10-19 17:48
To: Hollenbeck, Scott
CC: art-...@ietf.org; regext@ietf.org
Subject: Re: [regext] Internationalized Email Addresses and EPP
Hi, Scott,
An interesting question...
I think it depends upon how you want this to appear from an EPP point of view:
1. Do you want the EPP standard to support non-ASCII email addresses?
2. Do you want to *extend* EPP to support non-ASCII email addresses,
as an option for those who implement the extension?
For (2), then the EPP extension would be the easiest option, where the
extension would "update" 5733 and say that the extension changes the
definition to allow non-ASCII email addresses. The extension would be
at Proposed Standard, and 5733 would be at Internet Standard as it is
now.
For (1), the best way would be to revise 5733 and change the
definition of email address syntax, republishing it at Proposed
Standard and "obsolete" 5733. The protocol (the new RFC) would then
be back at Proposed Standard. You could then do a status change later
to move the new RFC to Internet Standard (without publishing yet
another revision).
So... does the working group want it to appear that support for
non-ASCII email addresses is an optional extension, or part of the
base EPP?
Barry
On Wed, Oct 14, 2020 at 7:54 AM Hollenbeck, Scott
wrote:
>
> Barry, Murray:
>
> We have a question about IETF process as it related to updating an Internet
> Standard document. RFC 5733 ("Extensible Provisioning Protocol (EPP) Contact
> Mapping", part of Standard 69) was published in August 2009. It includes a
> normative reference to RFC 5322 for the definition of email address syntax.
> RFC 6530 ("Overview and Framework for Internationalized Email") was published
> in 2012. The regext working group is discussing how we can best update the
> email address syntax specification in RFC 5733 to add support for the local
> part of internationalized email addresses to EPP. The EPP XML Schema already
> "works" as it should, so that doesn't need to change. It's just that pesky
> normative reference to RFC 5322 that isn't updated by RFC 6530. We think we
> have a couple of options:
>
> Create an EPP extension by writing an Internet-Draft that would explicitly
> add support for internationalized email address without touching anything
> associated with 5733.
>
> Write another document that updates 5733 to include the reference to 6530, if
> it's possible to update an Internet Standard that way.
>
> Submit an errata report to note the additional normative reference to 6530,
> though this isn't a technical or editorial error.
>
> There may be other possibilities. What are your thoughts on the best way to
> proceed? I personally think that the first option is the easiest and
> cleanest, and it's the way we've added additional functionality in the past.
> I'm wondering if there's an easier way, though.
>
> Scott
>
___
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] Genart telechat review of draft-ietf-regext-bundling-registration-11
> -原始邮件- > 发件人: "John C Klensin" > 发送时间: 2019-10-16 00:59:47 (星期三) > 收件人: "Joel M. Halpern" , "Jiankang Yao" > 抄送: gen-...@ietf.org, draft-ietf-regext-bundling-registration@ietf.org, > i...@ietf.org, regext@ietf.org > 主题: Re: [regext] Genart telechat review of > draft-ietf-regext-bundling-registration-11 > > Joel, > > Let me try one reason why this should not be Standards Track or, > if it should, it isn't ready. It uses, and is dependent on, > terminology for which there is no consensus definition and that > is used to describe different things in the wild. As I think I > suggested one of my earlier notes about this, it would be > possible to say "these terms mean whatever the registry says > they mean", explicitly anticipating that different registries > might use the extension for slightly different purposes. > Dear John, Thanks a lot for your kind review. As you mentioned it in other email, currently, there has no universally agreed definition about "variant". You said "it would be possible to say "these terms mean whatever the registry says they mean". I agree with your understanding. In this document, we focus on policy based domain name bundling. Different registry may have different policy for their bundling name registration based on EPP. The bundling name registration system is mainly used by the registry and its registrars. Some regards samename.TLD1 and samename.TLD2 as bundling names; some regards name1.TLD and name2.TLD as the bundling names. Here, name1 may be simple Chinese name verison, name2 may be traditional Chinese name version. What is name1 and what is name2 are defined by registry's own policy. The word "variant" only appear in the introduction of this document. If you think that the variant has not good definition, can we remove the "variant" word and use other word such as "bundling name"? Or do you have good text/words to kindly help to improve the document? Thanks a lot. Jiankang Yao ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11
> -原始邮件- > 发件人: "Joel Halpern via Datatracker" > 发送时间: 2019-10-11 06:56:18 (星期五) > 收件人: gen-...@ietf.org > 抄送: draft-ietf-regext-bundling-registration@ietf.org, i...@ietf.org, > regext@ietf.org > 主题: [regext] Genart telechat review of > draft-ietf-regext-bundling-registration-11 > > Reviewer: Joel Halpern > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-regext-bundling-registration-11 > Reviewer: Joel Halpern > Review Date: 2019-10-10 > IETF LC End Date: None > IESG Telechat date: 2019-10-17 Dear Joel Halpern, Thanks a lot for your kind review. > > Summary: This document is almost ready for publication as an RFC. > > I have received no response to my earlier review. Some of the items have been > addressed, but not all of them. > > Major issues: > This document clearly defines normative protocol behavior. As such, it > would seem to either be Experimental or Proposed Standard, but not > Informational. > Because the WG chair clarified this issue in the mailing list after your review, the WG decided that this document should go to informational. I thought you may be clear about it. So I did not directly response to this issue. Sorry about it. Some information about this issue from one of the co-chairs: https://mailarchive.ietf.org/arch/msg/regext/wPQdna8E6eHkF4co4XDxrNzHPls# https://mailarchive.ietf.org/arch/msg/regext/PILROKSKupLTh6tdVuye5b6ou1k > Minor issues: > The document incorporates items from a name space > "urn:ietf:params:xml:ns:epp:b-dn", referred to with the prefix "b-dn:". > The only explanation of this meaning is in the terminology section. > However, the description does not indicate what document defines this > information. > In section 10 "IANA Considerations", the XML namesapce and schema is defined. IANA will add a XML registry for this document at https://www.iana.org/assignments/xml-registry/xml-registry.xml. IANA is requested to assignment the two URIs. One is urn:ietf:params:xml:ns:epp:b-dn. So the XML information can be checked on this page. I hope that the above information can answer your concerns. Thanks a lot. Jiankang Yao > Nits/editorial comments: > I note and appreciate that my comments on the SHOULD usage in section 7.2 > has been addressed. > > > ___ > 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] New Version Notification - draft-ietf-regext-bundling-registration-11.txt
Thanks a lot. Jiankang Yao From: Barry Leiba Date: 2019-10-06 21:32 To: draft-ietf-regext-bundling-registration.all CC: regext Subject: Re: [regext] New Version Notification - draft-ietf-regext-bundling-registration-11.txt Thanks for this new version; I will send it to the IESG, and expect it on the 17 October telechat. Barry ___ 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] New-AD review of draft-ietf-regext-bundling-registration-09
-原始邮件- 发件人:"Barry Leiba" 发送时间:2019-09-26 12:17:10 (星期四) 收件人: "Jiankang Yao" 抄送: draft-ietf-regext-bundling-registration@ietf.org, regext@ietf.org 主题: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09 This remains quite incomplete: the last call comments have not been properly handled. In Sections 6.1, 6.2, 7.1.2, and all the 7.2.x you made changes in response to Adam’s AD review, but you tried to use the second of his suggested fixes. What you did do is flawed, as you have introduced a space character between the two U+ characters (which is why he advised against that fix, because doing it without the extra space makes it hard to read, but adding the space makes it wrong). Please fix that. I suggest using Adam’s XML-escaping example to fix it. Yao: Yes, we will use Adam's suggestion to fix it. thanks. The Gen-ART review asked for BCP 14 key words in Section 5, and you said you would add them. You did not. That’s fine if you ultimately decided not to (I personally think it is not necessary), but I want to make sure you didn’t simply forget to make that change. Yao:Yes, we ultimately think that we do not need to make the change. The Gen-ART review asked for a brief explanation of what the conditions might be for not complying with the “SHOULD” requirements in Sections 7.2.x, and what the consequences would be. You did not add that, and I think it’s necessary. Please add an explanation in each of those sections. Yao: We will add it. The SecDir review suggested changing the contact for the IANA registrations to the IETF, rather than the authors, and I agree: it should be “the IETF”, probably with the regext mailing list as the contact information. You did not make any change. Please do. You also did not address my comment about needing an explanation for why this is Informational and not Proposed Standard. It’s fine for it to be Informational, but the shepherd writeup needs to explain why (please update it), and the Introduction probably should also, assuming that reason has to do with the deployment, applicability, or maturity of what’s documented here. Yao: In the section "IANA Considerations" , we will add the following sentence " This document describes a non-standard EPP extension, so that the registrant contact will use author's address under the REGEXT WG's guidance." Thanks for your kind detail review.Best RegardsJiankang Yao I won’t pass this up to the IESG until all these points are addressed. So back into Revised I-D needed this goes, and please handle this without undue delay. Thanks, Barry On Sat, Sep 21, 2019 at 7:15 AM Jiankang Yao wrote: Dear Barry, The new version has been submitted. It addresses the comments received during IETF LC. https://datatracker.ietf.org/doc/html/draft-ietf-regext-bundling-registration-10 Thanks. Jiankang Yao > -原始邮件- > 发件人: "Jiankang Yao" > 发送时间: 2019-09-13 16:39:04 (星期五) > 收件人: "Barry Leiba" > 抄送: draft-ietf-regext-bundling-registration@ietf.org, regext@ietf.org > 主题: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09 > > > Thanks Barry. > We have finished an initial new version. We will refine it and submit it > within 2 weeks. > > Best Regards. > > Jiankang Yao > > > -原始邮件- > > 发件人: "Barry Leiba" > > 发送时间: 2019-09-13 09:21:02 (星期五) > > 收件人: "Jiankang Yao" > > 抄送: draft-ietf-regext-bundling-registration@ietf.org, regext@ietf.org > > 主题: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09 > > > > > Thanks a lot. We will update a new version based on your guidance. > > > > It's been almost 12 weeks. Is a new version forthcoming? When can we > > expect it? > > > > Barry > > > > > > 在 2019年6月22日，02:28，Barry Leiba ; 写道： > > > > > > > > Hey, regext folks, > > > > > > > > This document had an AD review from Adam, a Gen-ART review from Joel, > > > > and a SecDir review from Russ, and went through IETF last call. All > > > > three reviews were responded to on the regext mailing list (by > > > > Jiankang and by Antoine), but there has been no revision of the draft > > > > to address the issues raised. That has to happen. > > > > > > > > While we're there, there's the issue of the Informational status and > > > > the registrant contact for the namespace: > > > > > > > > It's my understanding that this isn't specifying a standard, but, > > > > rather, is documenting an existing non-standard extension that is not > > > > expected to be a s
Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
How about adding some explanation in the Shepherd write-up? Jiankang Yao From: Barry Leiba Date: 2019-09-27 23:29 To: Antoin Verschuren CC: Jiankang Yao; draft-ietf-regext-bundling-registration.all; regext Subject: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09 Thanks, Antoin; I agree with your analysis, and I agree that the contact info is fine as it is, given that. But this is also why I think it's important for the document to clearly say that this is documenting a proprietary extension, and that that is why it's Informational. Without that being clear, we're going to get pushback from the IESG about a few things. So let's be very clear about it. Makes sense? Barry On Fri, Sep 27, 2019 at 11:13 AM Antoin Verschuren wrote: > > Barry, > > I have not reviewed all the comments yet, but I am only responing to this one: > > The SecDir review suggested changing the contact for the IANA registrations > to the IETF, rather than the authors, and I agree: it should be “the IETF”, > probably with the regext mailing list as the contact information. You did > not make any change. Please do. > > > This is incorrect according to RFC4741, and I have replied to the SecDir > review on the list that it is as well. > Section 2.2.1. of RFC4741 states: > > Registrant Name and Email Address: The name and email address of the >person that is responsible for managing the registry entry. If the >registration is of an IETF Standards Track document, this can simply >be listed as "IESG, ”. > > > draft-ietf-regext-bundling-registration is NOT an IETF Standard Track > document. > draft-ietf-regext-bundling-registration is an IETF INFORMATIONAL document, > and it is for a reason. > The REGEXT working group did not consent that this draft produces a standard, > and therefor refused Standards track stream. > The REGEXT working group did allow the authors to document their proprietary > EPP extension in an informational IETF document, and adopted the document to > help review. > This informational document only documents a proprietary EPP extension. > > Proprietary EPP extensions are allowed in the IANA EPP Extensions registry, > with an informational RFC as one type of documentation, but they are > registered in the IANA registry with the name and email address of the one > that registers the proprietary extension, which is the authors and NOT the > IESG. Only Standard track documents are listed with the IESG as contact in > the IANA EPP extensions registry. > The purpose of the IANA EPP extensions registry is to eventually consolidate > all proprietary extensions to standards and the registered contact is one of > the recognition points if an EPP extension is a standard. > We do not want proprietary EPP extensions to become standards without consent > of the REGEXT working group. > > I can understand that this can be confusing for the IESG, since they mostly > review standards track documents as output from the REGEXT working group, but > this is one of the few exceptions that is deliberately an informational > document. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > Op 26 sep. 2019, om 06:17 heeft Barry Leiba het > volgende geschreven: > > This remains quite incomplete: the last call comments have not been properly > handled. > > In Sections 6.1, 6.2, 7.1.2, and all the 7.2.x you made changes in response > to Adam’s AD review, but you tried to use the second of his suggested fixes. > What you did do is flawed, as you have introduced a space character between > the two U+ characters (which is why he advised against that fix, because > doing it without the extra space makes it hard to read, but adding the space > makes it wrong). Please fix that. I suggest using Adam’s XML-escaping > example to fix it. > > The Gen-ART review asked for BCP 14 key words in Section 5, and you said you > would add them. You did not. That’s fine if you ultimately decided not to > (I personally think it is not necessary), but I want to make sure you didn’t > simply forget to make that change. > > The Gen-ART review asked for a brief explanation of what the conditions might > be for not complying with the “SHOULD” requirements in Sections 7.2.x, and > what the consequences would be. You did not add that, and I think it’s > necessary. Please add an explanation in each of those sections. > > The SecDir review suggested changing the contact for the IANA registrations > to the IETF, rather than the authors, and I agree: it should be “the IETF”, > probably with the regext mailing list as the contact information. You did > not make any change. Pl
Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
Dear Barry, The new version has been submitted. It addresses the comments received during IETF LC. https://datatracker.ietf.org/doc/html/draft-ietf-regext-bundling-registration-10 Thanks. Jiankang Yao > -原始邮件- > 发件人: "Jiankang Yao" > 发送时间: 2019-09-13 16:39:04 (星期五) > 收件人: "Barry Leiba" > 抄送: draft-ietf-regext-bundling-registration@ietf.org, regext@ietf.org > 主题: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09 > > > Thanks Barry. > We have finished an initial new version. We will refine it and submit it > within 2 weeks. > > Best Regards. > > Jiankang Yao > > > -原始邮件----- > > 发件人: "Barry Leiba" > > 发送时间: 2019-09-13 09:21:02 (星期五) > > 收件人: "Jiankang Yao" > > 抄送: draft-ietf-regext-bundling-registration@ietf.org, regext@ietf.org > > 主题: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09 > > > > > Thanks a lot. We will update a new version based on your guidance. > > > > It's been almost 12 weeks. Is a new version forthcoming? When can we > > expect it? > > > > Barry > > > > > > 在 2019年6月22日，02:28，Barry Leiba ; 写道： > > > > > > > > Hey, regext folks, > > > > > > > > This document had an AD review from Adam, a Gen-ART review from Joel, > > > > and a SecDir review from Russ, and went through IETF last call. All > > > > three reviews were responded to on the regext mailing list (by > > > > Jiankang and by Antoine), but there has been no revision of the draft > > > > to address the issues raised. That has to happen. > > > > > > > > While we're there, there's the issue of the Informational status and > > > > the registrant contact for the namespace: > > > > > > > > It's my understanding that this isn't specifying a standard, but, > > > > rather, is documenting an existing non-standard extension that is not > > > > expected to be a standard nor widely implemented. Is that correct? > > > > > > > > If so, the document should make that clear in the Abstract (briefly) > > > > and in the Introduction (somewhat less briefly). > > > > > > > > Also, the shepherd writeup doesn't help me understand why this is > > > > Informational, and it should: (from the writeup text, emphasis mine) > > > > "Explain briefly what the intent of the document is (the document's > > > > abstract is usually good for this), and WHY THE WORKING GROUP HAS > > > > CHOSEN THE REQUESTED PUBLICATION TYPE". You say the working group > > > > decided, but you don't say why. > > > > > > > > So: > > > > Please revise the draft to address the last call reviews, and also > > > > please add something to the Introduction (and possibly the Abstract) > > > > to explain the status of the document, making clear what the standards > > > > or non-standards status is and what applicability we expect for it. > > > > > > > > I'm putting this into a "Revised I-D Needed" substate, awaiting such > > > > revision. > > > > > > > > Thanks, > > > > Barry > > > > ___ > > 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 mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
Thanks Barry. We have finished an initial new version. We will refine it and submit it within 2 weeks. Best Regards. Jiankang Yao > -原始邮件- > 发件人: "Barry Leiba" > 发送时间: 2019-09-13 09:21:02 (星期五) > 收件人: "Jiankang Yao" > 抄送: draft-ietf-regext-bundling-registration@ietf.org, regext@ietf.org > 主题: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09 > > > Thanks a lot. We will update a new version based on your guidance. > > It's been almost 12 weeks. Is a new version forthcoming? When can we > expect it? > > Barry > > > > 在 2019年6月22日，02:28，Barry Leiba ; 写道： > > > > > > Hey, regext folks, > > > > > > This document had an AD review from Adam, a Gen-ART review from Joel, > > > and a SecDir review from Russ, and went through IETF last call. All > > > three reviews were responded to on the regext mailing list (by > > > Jiankang and by Antoine), but there has been no revision of the draft > > > to address the issues raised. That has to happen. > > > > > > While we're there, there's the issue of the Informational status and > > > the registrant contact for the namespace: > > > > > > It's my understanding that this isn't specifying a standard, but, > > > rather, is documenting an existing non-standard extension that is not > > > expected to be a standard nor widely implemented. Is that correct? > > > > > > If so, the document should make that clear in the Abstract (briefly) > > > and in the Introduction (somewhat less briefly). > > > > > > Also, the shepherd writeup doesn't help me understand why this is > > > Informational, and it should: (from the writeup text, emphasis mine) > > > "Explain briefly what the intent of the document is (the document's > > > abstract is usually good for this), and WHY THE WORKING GROUP HAS > > > CHOSEN THE REQUESTED PUBLICATION TYPE". You say the working group > > > decided, but you don't say why. > > > > > > So: > > > Please revise the draft to address the last call reviews, and also > > > please add something to the Introduction (and possibly the Abstract) > > > to explain the status of the document, making clear what the standards > > > or non-standards status is and what applicability we expect for it. > > > > > > I'm putting this into a "Revised I-D Needed" substate, awaiting such > > > revision. > > > > > > Thanks, > > > Barry > > ___ > 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] New-AD review of draft-ietf-regext-bundling-registration-09
Dear Barry, Thanks a lot. We will update a new version based on your guidance. Best Regards Jiankang Yao From my phone > 在 2019年6月22日，02:28，Barry Leiba 写道： > > Hey, regext folks, > > This document had an AD review from Adam, a Gen-ART review from Joel, > and a SecDir review from Russ, and went through IETF last call. All > three reviews were responded to on the regext mailing list (by > Jiankang and by Antoine), but there has been no revision of the draft > to address the issues raised. That has to happen. > > While we're there, there's the issue of the Informational status and > the registrant contact for the namespace: > > It's my understanding that this isn't specifying a standard, but, > rather, is documenting an existing non-standard extension that is not > expected to be a standard nor widely implemented. Is that correct? > > If so, the document should make that clear in the Abstract (briefly) > and in the Introduction (somewhat less briefly). > > Also, the shepherd writeup doesn't help me understand why this is > Informational, and it should: (from the writeup text, emphasis mine) > "Explain briefly what the intent of the document is (the document's > abstract is usually good for this), and WHY THE WORKING GROUP HAS > CHOSEN THE REQUESTED PUBLICATION TYPE". You say the working group > decided, but you don't say why. > > So: > Please revise the draft to address the last call reviews, and also > please add something to the Introduction (and possibly the Abstract) > to explain the status of the document, making clear what the standards > or non-standards status is and what applicability we expect for it. > > I'm putting this into a "Revised I-D Needed" substate, awaiting such revision. > > Thanks, > Barry ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Genart last call review of draft-ietf-regext-bundling-registration-09
> -原始邮件- > 发件人: "Joel Halpern via Datatracker" > 发送时间: 2019-03-08 07:33:32 (星期五) > 收件人: gen-...@ietf.org > 抄送: draft-ietf-regext-bundling-registration@ietf.org, i...@ietf.org, > regext@ietf.org > 主题: [regext] Genart last call review of > draft-ietf-regext-bundling-registration-09 > > Reviewer: Joel Halpern > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-regext-bundling-registration-09 > Reviewer: Joel Halpern > Review Date: 2019-03-07 > IETF LC End Date: 2019-03-15 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is almost ready for publication as some form of RFC > Thanks for your kind review. > Major issues: > This document defines protocol extensions and mandatory procedures to go > with them. As such, it seems it is either Experimental or Proposed > Standard, but not Informational. > This document was originally for proposed standard. After WG's discussion, the WG decides to move it as informational. > Minor issues: > Section 5 consists of a list of behavioral requirements that appear > normative, but do not use RFC 2119 language. If these are indeed > normative > behavioral requirements, the document should use RFC 2119 language to be > clear. (And therefore, should also include the text explaining and citing > RFC 2119.) > Yes, will update it. >The description in 7.2.1 of the EPP command seems lacking. After >saying that it needs an extension element, it says: > The element SHOULD contain a child element > that identifies the bundle namespace and the location of the bundle > name schema. > It is unclear when it is reasonable to omit this element. (We > normally include with "SHOULD" explanations of this sort.) It is unspecified > what format of the information in the element has. I suspect > that it is assumed to be the same as some other piece of EPP information, but > it does not say so. The only child element for given in the > schema is the which is neither a namespace identifier nor a > location > of the bundle name schema. > Thanks. We will consider to update it. > Again in 7.2.2 on the EPP command, when discussing the addition > to > the response, it is a SHOULD with no explanation of when it is okay to > omit > it. The same applies to the 7.2.3 EPP command, the 7.2.4 EPP > command, and the 7.2.5 EPP command. > Thanks. We will consider to change it to "MUST" or add some explanations. Best Regards. Jiankang Yao > Nits/editorial comments: > > > ___ > 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] AD Review: draft-ietf-regext-bundling-registration
< From: Adam Roach < Date: 2019-03-02 06:17 < To: draft-ietf-regext-bundling-registration.all < CC: Registration Protocols Extensions < Subject: AD Review: draft-ietf-regext-bundling-registration < This is my Area Director review for < draft-ietf-regext-bundling-registration. I < have a handful of comments on the document's comments, but none are of the < nature that preclude going into IETF last call, which should begin shortly. < Please treat my comments below the same as as IETF last call comments. < Thanks to everyone who worked on this specification. < --- Thanks a lot to AD's kind and detail review. < General: This document is grammatically incorrect or awkward in many < places in < a way that detracts from its readability. I believe it would benefit from an < editorial pass by a skilled editor. I call out specific issues in section 1 < below; however, in the interest of primarily reviewing the technical content < of this document, I have not indicated them for other sections. < --- < §1: < Bundled domain names are those which share the same TLD but whose xn-- < fsq270a.example < I presume that this would literally be: < xn--fsq270a.example < ...and that the use of the "U+" format is to deal with the current < restrictions on the RFC format, correct? If so, the handling of < quotation marks < in the preceding example is very confusing: XML requires attributes to be < fully enclosed in quotation marks, and the current example leaves ".example" < outside of them. < Consider using the XML escaping mechanism in these examples instead: < < xn--fsq270a.example < Alternately, if you want to use the format described in Section 2, this < would < look like: < xn--fsq270a.example < I would, however, advise using a different convention than this, as it is < somewhat difficult to read. < This same comment applies to other examples of the "uLabel" attribute as < well. < --- Thanks. We will see whether useor . either way has advantage and disadvantage. < §7.2.1: < The element SHOULD contain a child element that identifies the bundle namespace and the location of the bundle name schema. < This description appears to be somewhat incomplete; the example shows it < also < containing a element. Please either expand the text to < include the < purpose and meaning of the element in this context; or, if it < should < not be in the example, remove it from the example. < --- Ok, thanks. We will update it. < §8: < < < < < < < > < < < < < < Although there's nothing syntactically wrong with it, the use of < "trnDataType" < (implying "" operations) for all six operations is a bit < confusing. < Consider renaming something like "bundleDateType". < Good suggestion. We will consider to use "bundleDateType". Jiankang Yao < /a___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] New Version Notification for draft-ietf-regext-bundling-registration-09.txt
Hello all, Based on chair's guidance, this version fixed some warnings from IDNits. No other changes. Jiankang Yao From: internet-drafts Date: 2019-01-30 09:47 A new version of I-D, draft-ietf-regext-bundling-registration-09.txt has been successfully submitted by Jiankang Yao and posted to the IETF repository. Name: draft-ietf-regext-bundling-registration Revision: 09 Title: Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration Document date: 2019-01-29 Group: regext Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-ietf-regext-bundling-registration-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext-bundling-registration/ Htmlized: https://tools.ietf.org/html/draft-ietf-regext-bundling-registration-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-bundling-registration Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-bundling-registration-09 Abstract: This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of strict bundling registration of domain names. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names. 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___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] regarding draft-ietf-regext-bundling-registration
Thank a lot to chairs. We will update a new vesion to address the following comments soon. Jiankang Yao From: James Galvin Date: 2018-11-16 22:52 To: Registration Protocols Extensions Subject: [regext] regarding draft-ietf-regext-bundling-registration This document is currently at version 6 but there have been 3 comments on the list since this version was published. These will need to be addressed before this document can be submitted for publication. Here is the summary: 1. Scott Hollenbeck has noticed a missing IANA Considerations requirement. Please see his note on the list on 25 October 2018. 2. Justin Mack and Patrick Mevzek made a comment on 11 October 2018 about this specification’s interaction with DNSSEC. The Chairs suggest that the document should have its Security Considerations section expanded to note this issue. Specifically, that the document does not take a position regarding whether or not the names share a key, but that if a key is shared then the names share fate if there is a key compromise. 3. Patrick Mevzek also noted 2 November 2018 that the document could use UTF-8 encoding of some of its characters rather than the U+ encoding. As specified by RFC7997, the Chairs believe that this is just an editorial suggestion, not a requirement. As such we believe that the document editors may decide for themselves whether or not to include this change. The document editors need to create a version 7 of this document, addressing these issues, before the document can be submitted for publication. Thanks, Antoin and Jim ___ 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] draft-ietf-regext-bundling-registration and characters representation
Hellow Patrick Mevzek, Thanks. Your suggestion is very good. RFC7997 is an informational RFC, and shows a direction. Because the popular form of RFC is TXT, the TXT can not display non ASCII very well. I can use the natvie unicode characters in draft, but many readers will not display it correctly. According to my current understanding, U+ is still the proper way to be easily understood by most readers. Many years ago, IETF EAI WG also discussed this related issue. I still do not see which rfc uses the natvie unicode characters directly. If possilbe, I may suggest to add some texts in the draft, which says "in future, the natvie unicode characters instead of U+ notation are suggested to use in the document" Best Regards Jiankang Yao > -原始邮件- > 发件人: "Patrick Mevzek" > 发送时间: 2018-11-02 12:54:37 (星期五) > 收件人: regext@ietf.org > 抄送: > 主题: [regext] draft-ietf-regext-bundling-registration and characters > representation > > Hello, > > This draft, by essence, needs and uses a lot of characters outside of ASCII > and for these use the U+ notation. > > There is now however RFC7997 (The Use of Non-ASCII Characters in RFCs) and > among other things it says: > > - the encoding of future RFCs will be in UTF-8 > - Where the use of non-ASCII characters is purely part of an example >and not otherwise required for correct protocol operation, escaping >the non-ASCII character is not required. > - The RFC Editor encourages the use of the U+ notation except within a >code component where one must follow the rules of the programming >language in which the code is being written. > > > So maybe the XML examples could be rewritten by using the native unicode > characters > instead of the U+ notation, as I believe it would make them far more > understandable. > > In the text, the other recommendations of the above RFC could be applied to > have > more standardized handling. > > -- > Patrick Mevzek > p...@dotandco.com > > ___ > 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] draft-ietf-regext-bundling-registration-06.txt - Impact of DNSSEC?
From: Mack, Justin Date: 2018-10-31 02:31 To: regext@ietf.org Subject: Re: [regext] draft-ietf-regext-bundling-registration-06.txt - Impact of DNSSEC? >Greetings REGEXT, > >What is the impact of DNSSEC on bundled domain names in this specification? > I think that there has no direct impact. >I see that most attributes are shared between domains in the bundle, >such as assigned nameservers. Does this mean that DS/DNSKEY information >is also shared between these domains? > The DNS administrator can choose whether DS/DNSKEY information can be shared or not. This document does not specify it. >As a DNS administrator, I assume I must create separate zones for each >domain in the bundle, if I want them all to resolve. In the case of (TLDs are different) LABEL.V-tld-A and LABEL.V-tld-B, you must create separated zones. In the case of (TLD is same) V-label-A.TLD and V-label-B.TLD, you can choose to create separated zones or not. >Must I share the >same Key Signing Keys (KSKs) and even Zone Signing Keys (ZSKs) between >the bundled zones? > As pointed above, The DNS administrator can choose whether DS/DNSKEY information can be shared or not. This document does not specify it. Thanks. Jiankang Yao >Thank you. >___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Document Shepherd check on draft-ietf-regext-bundling-registration-05
Dear Scott, Thanks for your kind support and review. The version 06 has been updated to address your concerns. https://www.ietf.org/internet-drafts/draft-ietf-regext-bundling-registration-06.txt section 7.2.3. EPP Command section 7.2.4. EPP Command section 7.2.5. EPP Command have refined the text and added the example according to your kind suggestion. Section 11. Security Considerations has been updated to add some words related security. CNNIC and some other registries have implemented this document, and tested the examples. Thanks a lot. Jiankang Yao From: Hollenbeck, Scott Date: 2018-10-02 19:29 To: 'j...@afilias.info'; 'regext@ietf.org' Subject: Re: [regext] Document Shepherd check on draft-ietf-regext-bundling-registration-05 I don’t recall seeing any discussion of or text changes to address my feedback. Here’s my note: https://www.ietf.org/mail-archive/web/regext/current/msg01541.html Scott From: regext On Behalf Of Joseph Yee Sent: Monday, October 01, 2018 5:15 PM To: regext@ietf.org Subject: [EXTERNAL] [regext] Document Shepherd check on draft-ietf-regext-bundling-registration-05 HI all, I'm the document shepherd of draft-ietf-regext-bundling-registration-05. During review. The WG had made a last call on its -03 version (subject: [regext] WGLC: draft-ietf-regext-bundling-registration-03), and Scott Hollenbeck supported the publication but also raised concern on security consideration. I have not see any further discussion on this, I would like to ask whether WG closed the issue. Thanks to all. Best, Joseph ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Document Shepherd check on draft-ietf-regext-bundling-registration-05
Thanks Scott and Joseph. I will update a new version to address it. Jiankang Yao From my phone > 在 2018年10月2日，19:29，Hollenbeck, Scott > 写道： > > I don’t recall seeing any discussion of or text changes to address my > feedback. Here’s my note: > > https://www.ietf.org/mail-archive/web/regext/current/msg01541.html > > Scott > > From: regext On Behalf Of Joseph Yee > Sent: Monday, October 01, 2018 5:15 PM > To: regext@ietf.org > Subject: [EXTERNAL] [regext] Document Shepherd check on > draft-ietf-regext-bundling-registration-05 > > HI all, > > I'm the document shepherd of draft-ietf-regext-bundling-registration-05. > During review. The WG had made a last call on its -03 version (subject: > [regext] WGLC: draft-ietf-regext-bundling-registration-03), and Scott > Hollenbeck supported the publication but also raised concern on security > consideration. > > I have not see any further discussion on this, I would like to ask whether WG > closed the issue. Thanks to all. > > Best, > Joseph > > ___ > 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] Proposed Changes to Milestones
Dear Antoin Verschuren, Some comments are inline below. Thanks. 发件人:"Antoin Verschuren" <i...@antoin.nl> 发送时间:2017-05-22 18:11:41 (星期一) 收件人: "Registration Protocols Extensions" <regext@ietf.org> 抄送: 主题: Re: [regext] Proposed Changes to Milestones >If we cannot get enough consensus on the bundling and IDN drafts because there >is no clear technical solution, demand or traction yet, > For strict bundling registration, there is clear technical solution, demand or traction , especially for those registries who sell Chinese Domain Names. The mechanisms described in draft-ietf-regext-bundling-registration have been adopted by many registries such as CNNIC, TWNIC, HKIRC and DotASIA. The proposed mechanisms have been used since 2003. If someone tries to combine both relax bundling and strict bundling together, I agree that there are no easy solution. But for separated documents, the strict bundling document(draft-ietf-regext-bundling-registration ) is clear and enough to be pushed forward. >a pragmatic proposal could also be to delete them from our milestones for now, > I do not agree with it here. I suggest to keep the strict bundling registration document and move it forward. This document is very useful for those who plan to use strict bundling registration. > >We’re interested on your thoughts. Pls see above. Thanks a lot. Jiankang Yao Op 19 mei 2017, om 17:01 heeft Roger D Carney <rcar...@godaddy.com> het volgende geschreven: Good Morning, Thanks Jim/Antoin for working through all of these documents. I think these updates look good, except for a question on the reseller documents. As I mentioned on list back in March, I thought in Seoul we decided to review and comment but to not dedicate WG effort to these drafts? As far as the bundling and idn drafts, I have not followed these with too much intensity so I will defer to others on these documents. Thanks Roger -Original Message- From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin Sent: Friday, May 19, 2017 8:41 AM To: Registration Protocols Extensions <regext@ietf.org> Subject: [regext] Proposed Changes to Milestones During the last IETF meeting we had a request to adopt another document. As part of that discussion our AD expressed concern about the number of documents currently on our list and the number of milestones currently on our list. The Chairs took an action to review both of these and we now have a proposal for consideration by the working group. To see the list of current milestones review this link: https://datatracker.ietf.org/group/regext/about/ To see the list of current documents review this link: https://datatracker.ietf.org/group/regext/documents/ The Chairs have contacted the authors of all documents and asked for their feedback regarding the status of their document, reviewed the current proposed milestone dates, and propose the following. These are shown as they are listed in the current milestones. draft-ietf-regext-launchphase WGLC finished. Waiting for shepherd write-up adjustments before submitting to IESG. Action: Change milestone date to June 2017. draft-ietf-regext-tmch-func-spec Status changed to Informational. Changed to Parked document. Action: Delete from milestone list. draft-ietf-regext-epp-rdap-status-mapping RFC 8056 Action: Set Status Resolved on milestone list. draft-ietf-regext-epp-fees Recent version submitted. Active discussion. Action: Change milestone date to July 2017. draft-ietf-regext-reseller draft-ietf-regext-reseller-ext These drafts have been replaced by draft-ietf-regext-org and draft-ietf-regext-org-ext. Active discussion. Action: Accept new documents, replace on milestones, Change milestone date to Nov 2017. draft-gould-eppext-verificationcode No reaction from authors. Action: Replace to draft-ietf-regext-verificationcode on milestone list Change milestone date to June 2018. draft-xie-eppext-nv-mapping (current milestone listing but document is really draft-ietf-regext-nv-mappgin) Informational document, waiting for draft-ietf-regext-verificationcode Action: Change to parked document. Delete from milestone list. draft-gould-change-poll (change to draft-ietf-regext-change-poll) Needs more reviewers and implementation. Action: Change milestone date to Nov 2017. draft-gould-allocation-token (change to draft-ietf-regext-allocation-token) Needs implementation status section and review. Action: Change milestone date to Nov 2017. draft-ietf-regext-bundling-registration New version submitted for STRICT bundling. draft-ietf-eppext-idnmap draft-gould-idn-table draft-cira-regext-idn These documents have discussion but no consensus. All these documents relate. Some want all IDN to be included in bundling discussion. Act
Re: [regext] question regarding status draft-ietf-regext-bundling-registration
From: Marc Blanchet Date: 2016-12-03 05:09 To: James Galvin CC: Registration Protocols Extensions Subject: Re: [regext] question regarding status draft-ietf-regext-bundling-registration >I have said on the mike two meetings ago that there are multiple >bundling drafts and instead of having many, the co-authors should work >on a common framework/document. There has been some initial >communications between them offline but more to come. > yes, we have some offline discussion. currently, there are two kinds of bundling: strict bundling specified in draft-ietf-regext-bundling-registration and relax bundling specified in draft-wilcox-cira-idn-eppext. We have try to merge to these two kinds of bundling together, but it seems that it is not easy to do so. We initiated the text for common bundling for discusssion a few months ago, but there has no big progress. >I would suggest >that we shall work towards a single framework instead of multiple >incompatible ones. my suggestion is that: we still have co-operation to move the current strict bundling draft and relax bunding draft ahead. At same time, we also discuss whether we can produce a common bundling draft. >For DNSbundled bof, I think nothing prevents the >publication of an regext epp extension that would work on specific >contexts and current deployments, while having another thread working on >the larger issue. yes, agree. Jiankang Yao > >Marc.___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
