Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration
draft-yao-regext-bundling-registration-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-07-27
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-07-12
|
06 | (System) | RFC Editor state changed to AUTH48 |
2021-06-16
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-06-09
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-06-09
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-06-09
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-06-07
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-06-04
|
06 | (System) | IANA Action state changed to In Progress |
2021-06-04
|
06 | (System) | RFC Editor state changed to EDIT |
2021-06-04
|
06 | Adrian Farrel | Tag IESG Review Completed cleared. |
2021-06-04
|
06 | Adrian Farrel | ISE state changed to Sent to the RFC Editor from In IESG Review |
2021-06-04
|
06 | Adrian Farrel | Sent request for publication to the RFC Editor |
2021-06-04
|
06 | (System) | Revised ID Needed tag cleared |
2021-06-04
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-06-04
|
06 | Jiankang Yao | New version available: draft-yao-regext-bundling-registration-06.txt |
2021-06-04
|
06 | (System) | New version approved |
2021-06-04
|
06 | (System) | Request for posting confirmation emailed to previous authors: Hongtao Li , Jiagui Xie , Jiankang Yao , Linlin Zhou , Ning Kong , Wil Tan |
2021-06-04
|
06 | Jiankang Yao | Uploaded new revision |
2021-06-02
|
05 | Adrian Farrel | Tags Revised I-D Needed, IESG Review Completed set. |
2021-05-03
|
05 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed |
2021-05-03
|
05 | Amanda Baber | (Via drafts-eval@iana.org): IESG/Authors/ISE: The IANA Functions Operator has completed its review of draft-yao-regext-bundling-registration-05. If any part of this review is inaccurate, please let us … (Via drafts-eval@iana.org): IESG/Authors/ISE: The IANA Functions Operator has completed its review of draft-yao-regext-bundling-registration-05. If any part of this review is inaccurate, please let us know. We understand that when this document is sent to us for processing, we will perform three registry actions. First, epp:b-dn will be added to the IETF XML ns registry at https://www.iana.org/assignments/xml-registry. Second, epp:b-dn will be added to the IETF XML schema registry at https://www.iana.org/assignments/xml-registry. Third, the following entry will be added to the Extensions for the Extensible Provisioning Protocol (EPP) registry at https://www.iana.org/assignments/epp-extensions: Name of Extension: Domain Name Mapping Extension for Strict Bundling Registration Document Status: Informational Reference: this document Registrant: See "Author's Address" section of this document TLDs: Any IPR Disclosure: https://datatracker.ietf.org/ipr/2479 Status: Active Notes: None Thank you, Amanda Baber Lead IANA Services Specialist |
2021-05-03
|
05 | Amanda Baber | Changes in version 05 approved. |
2021-05-03
|
05 | Amanda Baber | IANA Experts State changed to Expert Reviews OK from Issues identified |
2021-05-03
|
05 | Jiankang Yao | New version available: draft-yao-regext-bundling-registration-05.txt |
2021-05-03
|
05 | (System) | New version approved |
2021-05-03
|
05 | (System) | Request for posting confirmation emailed to previous authors: Hongtao Li , Jiagui Xie , Jiankang Yao , Linlin Zhou , Ning Kong , Wil Tan |
2021-05-03
|
05 | Jiankang Yao | Uploaded new revision |
2021-04-23
|
04 | Jiankang Yao | New version available: draft-yao-regext-bundling-registration-04.txt |
2021-04-23
|
04 | (System) | New version approved |
2021-04-23
|
04 | (System) | Request for posting confirmation emailed to previous authors: Hongtao Li , Jiagui Xie , Jiankang Yao , Linlin Zhou , Ning Kong , Wil Tan |
2021-04-23
|
04 | Jiankang Yao | Uploaded new revision |
2021-04-20
|
03 | Amanda Baber | EPP Extensions expert: 1. Sections 9.1.1 and 9.1.2 describe an "IDN namespace" and an "IDN XML Schema", but I *think* these should refer to a … EPP Extensions expert: 1. Sections 9.1.1 and 9.1.2 describe an "IDN namespace" and an "IDN XML Schema", but I *think* these should refer to a "BDN namespace" and a "BDN XML Schema" to match the values in the URIs that are being registered. If that's the case, the text should be updated. 2. Section 9.2 includes a URL for the generic Datatracker IPR page. I believe it should point to this specific IPR declaration: https://datatracker.ietf.org/ipr/2479/ With these changes it would be OK. ==== XML ns/schema expert: The registrations are mostly OK. They need the schemaLocation attributes stripped though. The XML namespace prefix "b-dn" is used for the namespace "urn:ietf:params:xml:ns:epp:b-dn", but implementations must not rely on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. This is mostly OK, but it creates a bad impression. It implies that a certain prefix might be privileged, which is not possible. This could instead say that ``This document uses the prefix "b-dn" for the namespace "urn..." throughout. Implementations cannot assume that any particular prefix is used and MUST employ a namespace-aware XML parser...``. Either that or the paragraph could be removed entirely. |
2021-04-20
|
03 | Amanda Baber | IANA Experts State changed to Issues identified |
2021-04-17
|
03 | Adrian Farrel | draft-yao-regext-bundling-registration has been brought to the ISE for publication as an Informational RFC in the Independent Submissions Stream. Previously, this work advanced through the EPPEXT … draft-yao-regext-bundling-registration has been brought to the ISE for publication as an Informational RFC in the Independent Submissions Stream. Previously, this work advanced through the EPPEXT and then the REGEXT working group as draft-ietf-regext-bundling-registration. That document passed working group last call, AD review, and IETF last call before being assessed by the IESG. The IESG ballot shows one Discuss (about the intended status of the document, and whether it should be presented as a proprietary solution). More notably, it appears that the IESG determined that the WG and IETF last calls amounted to "consensus by silence," and that the IETF had no reason to care about advancing the document. Barry Leibe, the responsible AD at the time, was convinced by the arguments and suggested to the authors that they try the Independent Stream. The document was reviewed for the ISE by Yoshiro Yoneya who has experience of registry management through his work at Japan Registry Services. His review is shown below, as is the ISE's review. all comments have been addressed satisfactorily. John Klensin also sent significant comments and suggested text to the authors who made changes accordingly. The question of whether this document is of broad enough interest to the wider community (or just to the registries that implement it) is to some extent answered in the Introduction by the text: This extension is especially useful for registries of practicing Chinese domain name registration. This method is also useful for other language domain names that have similar issues with Chinese domain names. The final document makes it clear that this is a proprietary specification both in the Abstract... This is a non-standard proprietary extension. ...and in the Introduction... This document describes a non-standard proprietary extension. Note that there is IPR disclosed against the original document at https://datatracker.ietf.org/ipr/2479/ when the document was in the EPPEXT working group. A final point of note is that this document asks for IANA action that is from registries that use the "Specification Required" allocation policy. That means that review by a DE is required. The original REGEXT document had already progressed through DE review and so we expect that a further review is just a formality. ** Yoshiro Yoneya review ** Page 3: 1st paragraph In this paragraph, the term 'V-label' and 'V-tld' are introduced. V-label is said that 'shared the same TLD' but 'V-tld' is not. It should be explicitly explained that V-tld must be managed by the same entity. Page 3: last paragraph Although original intention of bundling is for Chinese Domain Names, it will be useful adding notes that this method is applicable for other language domain names that have variants. Page 4: 2. Terminology, 2nd paragraph "LABEL.Variants" and "Variants.LABEL" notation is differ from Page3, "LABEL.V-tld" and "V-label.TLD". Notation of technical term have to be consistend in whole document. The last sentence, "..., those TLDs should be controlled by the same registry" will be more clear "..., those TLDs must be managed by the same entity". Page 5: 3. Definitions I don't see clear distinction between "Terminology" section and "Definitions" section. Those can be mereged into one section. Page 5: 4. Overview, 3rd paragraph Before the last sentence, there should be explanation that there are "allocatable" bundled names and "blocked" bundled names. Both bundled names are in one package, but some objects such as name server association and domain status are not synchronized (registrants can't modify any object of blocked bundled names). I believe this is very important concept of bundled names, but it is not addressed in this document. This document seems assuming any bundled names are all allocatable bundled names. Informative reference to LGR (RFC 7940) and ICANN Root/SLD LGR works will be very helpful. Page 6: 2nd paragraph The 3rd point, "o When performing a domain Create, either of the bundle names will be accepted. If the domain name is available, both BDN and RDN will be registered." is contradictional. The label (domain name) used for domain create it is always RDN. Apparantly from its definition, BDN is delivarable of RDN. Page 8: Example response: As its nature of variants, BDNs for a RDN could be tens of thousands or more. This fact means that the response of for BDNs will be huge size. Therefore, there must be some mechanisms to eliminate huge response, such as indicating numbers of BDNs and temporal download URI for all of BDNs. Otherwise, this could be DoS mechanism for both registries and registrars. Page 9: Example response for an authorized client: As mentioned above, BDNs have "allocatable" or "blocked" attribute also. Those must be included in the response. Response size issue commented at command is issue here also. Page 11: 7.2.1. EPP Command I can't understand meaning for extension. Is it for specifying uLabel? If so, why A-Label in is insufficient? Clarification of extention meaning is very much appreciated. Page 12: Example response: Please refer comments for command above (for Page 8). Page 13: 7.2.2. EPP Command Please refer comments for command above (for Page 8). Page 14: 7.2.3. EPP Command Please refer comments for command above (for Page 8). Page 16: Example response: Please refer comments for command above (for Page 8). Page 17: Example response: Please refer comments for command above (for Page 8). Page 21: 1st paragraph I assume this paragraph is going to say "zone file for RDN and BDNs can be different even though served by the same name server." If this document mandates domain objects of RDN/BDNs (except for "blocked" BDNs) are bundled and being the same (synchronized), DS/DNSKEY records have to be the same as well. And if it is correct, this paragraph should say "Because RDN/BDNs share the same DS/DNSKEY information, signing keys for those zones must be the same, therefore, the bundled domain names share fate if there is a key compromise." ** ISE review ** ==Question== Is there an issue to consider about interop between implementations that do and do not support the extensions in this document. This would happen either if a client that supports this document sends a request to a server that does not support this document (I think that is safe from my understanding of this draft), or if a client that does not support this document receives a response from a server that does support it (I think this is more of a risk, but I suspect that RFC 5731 may cover this. It could be nice to add a few lines of text just to reassure people that there are no issues. ==Rewrite== The IANA section could usefully indicate the name of the registry so IANA can easily determine what action to take. Also, I think it will make things easier to follow it you break section 9 into subsections. So... OLD 9. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. IANA is requested to assignment the following two URIs. Registration request for the IDN namespace: o URI: urn:ietf:params:xml:ns:epp:b-dn o Registrant Contact: See the "Author's Address" section of this document. o XML: None. Namespace URI does not represent an XML specification. Registration request for the IDN XML schema: o URI: urn:ietf:params:xml:schema:epp:b-dn o Registrant Contact: See the "Author's Address" section of this document. o XML: See the "Formal Syntax" section of this document. The EPP extension described in this document should be registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. The details of the registration are as follows: o Name of Extension: "Domain Name Mapping Extension for Strict Bundling Registration" o Document status: Informational o Reference: This document o Registrant Name and Email Address: See the "Author's Address" section of this document. o Top-Level Domains (TLDs): Any o IPR Disclosure: https://datatracker.ietf.org/ipr/ o Status: Active o Notes: None NEW 9. IANA Considerations 9.1. XML Namespace and XML Schema This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. 9.1.1. IDN Namespace IANA is requested to make an assignment from the IETF XML Registry "ns" registry as follows for the IDN namespace with this document as the reference: o URI: urn:ietf:params:xml:ns:epp:b-dn o Registrant Contact: See the "Author's Address" section of this document. o XML: None. Namespace URI does not represent an XML specification. 9.1.2. IDN XML Schema IANA is requested to make an assignment from the IETF XML Registry "schema" registry as follows for the IDN XML schema with this document as the reference: o URI: urn:ietf:params:xml:schema:epp:b-dn o Registrant Contact: See the "Author's Address" section of this document. o XML: See the "Formal Syntax" section of this document. 9.2. EPP Extension The EPP extension described in this document should be registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. The details of the registration are as follows: o Name of Extension: "Domain Name Mapping Extension for Strict Bundling Registration" o Document status: Informational o Reference: This document o Registrant Name and Email Address: See the "Author's Address" section of this document. o Top-Level Domains (TLDs): Any o IPR Disclosure: https://datatracker.ietf.org/ipr/ o Status: Active o Notes: None END ==Nits== 1. s/In RFC4290/In RFC4290 [RFC4290]/ s/according the domain/according to the domain/ s/the same TLD/the same Top Level Domain (TLD)/ s/For an example, Public/For example, the Public/ s/label(LABEL)/label (LABEL)/ s/names to share many same/names to share many of the same/ s/transferring of any/transferring any/ s/bundling names registration/bundling name registration/ s/variant IDNs should/variant Internationalized Domain Name (IDNs) should/ 2. s/according the domain/according to the domain/ OLD The Registered Domain Name(RDN) and Bundled Domain Name(BDN) are used in this document. NEW The terms Registered Domain Name (RDN) and Bundled Domain Name (BDN) are used in this document. END OLD In the current practice, BDN's number will usually be kept to one according to the registration policy set by the registry. NEW In current practice, the number of BDNs is usually be kept to one according to the registration policy set by the registry. END 3. OLD that property of all other domain objects in the bundle package will be updated at the same time. NEW that property will be updated at the same time for all other domain objects in the bundle package. END 4. s/some parameter or attributes/some parameters or attributes/ Second bullet list. Can you format the bullets with: - all text indented and aligned - a blank line between bullets 4. In the second bullet list, you have EPP commands in different cases for example, domain transfer and domain Create. For clarity, I think these might usefully always be capitalised as Domain Transfer and Domain Create. Note, however, that 5731 uses "EPP " or simply "". You probably want to mirror that way of doing things since it is consistent with later on in the document. 6.1.2 s/changed,see/changed, see/ 6.2.1 s/When an command/When a command/ s/if an command/if a command/ 8. s/use of UTF-8 is recommend./use of UTF-8 is recommended./ s/the elements, element/the elements, and element/ 10. s/more than 15 years/more than 15 years experience/ |
2021-04-17
|
03 | Adrian Farrel | ISE state changed to In IESG Review from In ISE Review |
2021-04-17
|
03 | Adrian Farrel | IETF conflict review initiated - see conflict-review-yao-regext-bundling-registration |
2021-04-17
|
03 | Adrian Farrel | draft-yao-regext-bundling-registration has been brought to the ISE for publication as an Informational RFC in the Independent Submissions Stream. Previously, this work advanced through the REGEXT … draft-yao-regext-bundling-registration has been brought to the ISE for publication as an Informational RFC in the Independent Submissions Stream. Previously, this work advanced through the REGEXT working group as draft-ietf-regext-bundling-registration. That document passed working group last call, AD review, and IETF last call before being assessed by the IESG. The IESG ballot shows one Discuss (about the intended status of the document, and whether it should be presented as a proprietary solution). More notably, it appears that the IESG determined that the WG and IETF last calls amounted to "consensus by silence," and that the IETF had no reason to care about advancing the document. Barry Leibe, the responsible AD at the time, was convinced by the arguments and suggested to the authors that they try the Independent Stream. The document was reviewed for the ISE by Yoshiro Yoneya who has experience of registry management through his work at Japan Registry Services. His review is shown below, as is the ISE's review. all comments have been addressed satisfactorily. John Klensin also sent significant comments and suggested text to the authors who made changes accordingly. The question of whether this document is of broad enough interest to the wider community (or just to the registries that implement it) is to some extent answered in the Introduction by the text: This extension is especially useful for registries of practicing Chinese domain name registration. This method is also useful for other language domain names that have similar issues with Chinese domain names. The final document makes it clear that this is a proprietary specification both in the Abstract... This is a non-standard proprietary extension. ...and in the Introduction... This document describes a non-standard proprietary extension. A final point of note is that this document asks for IANA action that is from registries that use the "Specification Required" allocation policy. That means that review by a DE is required. The original REGEXT document had already progressed through DE review and so we expect that a further review is just a formality. ** Yoshiro Yoneya review ** Page 3: 1st paragraph In this paragraph, the term 'V-label' and 'V-tld' are introduced. V-label is said that 'shared the same TLD' but 'V-tld' is not. It should be explicitly explained that V-tld must be managed by the same entity. Page 3: last paragraph Although original intention of bundling is for Chinese Domain Names, it will be useful adding notes that this method is applicable for other language domain names that have variants. Page 4: 2. Terminology, 2nd paragraph "LABEL.Variants" and "Variants.LABEL" notation is differ from Page3, "LABEL.V-tld" and "V-label.TLD". Notation of technical term have to be consistend in whole document. The last sentence, "..., those TLDs should be controlled by the same registry" will be more clear "..., those TLDs must be managed by the same entity". Page 5: 3. Definitions I don't see clear distinction between "Terminology" section and "Definitions" section. Those can be mereged into one section. Page 5: 4. Overview, 3rd paragraph Before the last sentence, there should be explanation that there are "allocatable" bundled names and "blocked" bundled names. Both bundled names are in one package, but some objects such as name server association and domain status are not synchronized (registrants can't modify any object of blocked bundled names). I believe this is very important concept of bundled names, but it is not addressed in this document. This document seems assuming any bundled names are all allocatable bundled names. Informative reference to LGR (RFC 7940) and ICANN Root/SLD LGR works will be very helpful. Page 6: 2nd paragraph The 3rd point, "o When performing a domain Create, either of the bundle names will be accepted. If the domain name is available, both BDN and RDN will be registered." is contradictional. The label (domain name) used for domain create it is always RDN. Apparantly from its definition, BDN is delivarable of RDN. Page 8: Example response: As its nature of variants, BDNs for a RDN could be tens of thousands or more. This fact means that the response of for BDNs will be huge size. Therefore, there must be some mechanisms to eliminate huge response, such as indicating numbers of BDNs and temporal download URI for all of BDNs. Otherwise, this could be DoS mechanism for both registries and registrars. Page 9: Example response for an authorized client: As mentioned above, BDNs have "allocatable" or "blocked" attribute also. Those must be included in the response. Response size issue commented at command is issue here also. Page 11: 7.2.1. EPP Command I can't understand meaning for extension. Is it for specifying uLabel? If so, why A-Label in is insufficient? Clarification of extention meaning is very much appreciated. Page 12: Example response: Please refer comments for command above (for Page 8). Page 13: 7.2.2. EPP Command Please refer comments for command above (for Page 8). Page 14: 7.2.3. EPP Command Please refer comments for command above (for Page 8). Page 16: Example response: Please refer comments for command above (for Page 8). Page 17: Example response: Please refer comments for command above (for Page 8). Page 21: 1st paragraph I assume this paragraph is going to say "zone file for RDN and BDNs can be different even though served by the same name server." If this document mandates domain objects of RDN/BDNs (except for "blocked" BDNs) are bundled and being the same (synchronized), DS/DNSKEY records have to be the same as well. And if it is correct, this paragraph should say "Because RDN/BDNs share the same DS/DNSKEY information, signing keys for those zones must be the same, therefore, the bundled domain names share fate if there is a key compromise." ** ISE review ** ==Question== Is there an issue to consider about interop between implementations that do and do not support the extensions in this document. This would happen either if a client that supports this document sends a request to a server that does not support this document (I think that is safe from my understanding of this draft), or if a client that does not support this document receives a response from a server that does support it (I think this is more of a risk, but I suspect that RFC 5731 may cover this. It could be nice to add a few lines of text just to reassure people that there are no issues. ==Rewrite== The IANA section could usefully indicate the name of the registry so IANA can easily determine what action to take. Also, I think it will make things easier to follow it you break section 9 into subsections. So... OLD 9. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. IANA is requested to assignment the following two URIs. Registration request for the IDN namespace: o URI: urn:ietf:params:xml:ns:epp:b-dn o Registrant Contact: See the "Author's Address" section of this document. o XML: None. Namespace URI does not represent an XML specification. Registration request for the IDN XML schema: o URI: urn:ietf:params:xml:schema:epp:b-dn o Registrant Contact: See the "Author's Address" section of this document. o XML: See the "Formal Syntax" section of this document. The EPP extension described in this document should be registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. The details of the registration are as follows: o Name of Extension: "Domain Name Mapping Extension for Strict Bundling Registration" o Document status: Informational o Reference: This document o Registrant Name and Email Address: See the "Author's Address" section of this document. o Top-Level Domains (TLDs): Any o IPR Disclosure: https://datatracker.ietf.org/ipr/ o Status: Active o Notes: None NEW 9. IANA Considerations 9.1. XML Namespace and XML Schema This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. 9.1.1. IDN Namespace IANA is requested to make an assignment from the IETF XML Registry "ns" registry as follows for the IDN namespace with this document as the reference: o URI: urn:ietf:params:xml:ns:epp:b-dn o Registrant Contact: See the "Author's Address" section of this document. o XML: None. Namespace URI does not represent an XML specification. 9.1.2. IDN XML Schema IANA is requested to make an assignment from the IETF XML Registry "schema" registry as follows for the IDN XML schema with this document as the reference: o URI: urn:ietf:params:xml:schema:epp:b-dn o Registrant Contact: See the "Author's Address" section of this document. o XML: See the "Formal Syntax" section of this document. 9.2. EPP Extension The EPP extension described in this document should be registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. The details of the registration are as follows: o Name of Extension: "Domain Name Mapping Extension for Strict Bundling Registration" o Document status: Informational o Reference: This document o Registrant Name and Email Address: See the "Author's Address" section of this document. o Top-Level Domains (TLDs): Any o IPR Disclosure: https://datatracker.ietf.org/ipr/ o Status: Active o Notes: None END ==Nits== 1. s/In RFC4290/In RFC4290 [RFC4290]/ s/according the domain/according to the domain/ s/the same TLD/the same Top Level Domain (TLD)/ s/For an example, Public/For example, the Public/ s/label(LABEL)/label (LABEL)/ s/names to share many same/names to share many of the same/ s/transferring of any/transferring any/ s/bundling names registration/bundling name registration/ s/variant IDNs should/variant Internationalized Domain Name (IDNs) should/ 2. s/according the domain/according to the domain/ OLD The Registered Domain Name(RDN) and Bundled Domain Name(BDN) are used in this document. NEW The terms Registered Domain Name (RDN) and Bundled Domain Name (BDN) are used in this document. END OLD In the current practice, BDN's number will usually be kept to one according to the registration policy set by the registry. NEW In current practice, the number of BDNs is usually be kept to one according to the registration policy set by the registry. END 3. OLD that property of all other domain objects in the bundle package will be updated at the same time. NEW that property will be updated at the same time for all other domain objects in the bundle package. END 4. s/some parameter or attributes/some parameters or attributes/ Second bullet list. Can you format the bullets with: - all text indented and aligned - a blank line between bullets 4. In the second bullet list, you have EPP commands in different cases for example, domain transfer and domain Create. For clarity, I think these might usefully always be capitalised as Domain Transfer and Domain Create. Note, however, that 5731 uses "EPP " or simply "". You probably want to mirror that way of doing things since it is consistent with later on in the document. 6.1.2 s/changed,see/changed, see/ 6.2.1 s/When an command/When a command/ s/if an command/if a command/ 8. s/use of UTF-8 is recommend./use of UTF-8 is recommended./ s/the elements, element/the elements, and element/ 10. s/more than 15 years/more than 15 years experience/ |
2021-04-17
|
03 | Adrian Farrel | ISE state changed to In ISE Review from Response to Review Needed |
2021-04-02
|
03 | (System) | Revised ID Needed tag cleared |
2021-04-02
|
03 | Jiankang Yao | New version available: draft-yao-regext-bundling-registration-03.txt |
2021-04-02
|
03 | (System) | New version approved |
2021-04-02
|
03 | (System) | Request for posting confirmation emailed to previous authors: Hongtao Li , Jiagui Xie , Jiankang Yao , Linlin Zhou , Ning Kong , Wil Tan |
2021-04-02
|
03 | Jiankang Yao | Uploaded new revision |
2021-03-19
|
02 | Adrian Farrel | Tag Revised I-D Needed set. |
2021-03-19
|
02 | Adrian Farrel | ISE state changed to Response to Review Needed from In ISE Review |
2021-02-17
|
02 | Adrian Farrel | ISE state changed to In ISE Review from Response to Review Needed |
2021-02-17
|
02 | (System) | Revised ID Needed tag cleared |
2021-02-17
|
02 | Jiankang Yao | New version available: draft-yao-regext-bundling-registration-02.txt |
2021-02-17
|
02 | (System) | New version approved |
2021-02-17
|
02 | (System) | Request for posting confirmation emailed to previous authors: Hongtao Li , Jiagui Xie , Jiankang Yao , Linlin Zhou , Ning Kong , Wil Tan |
2021-02-17
|
02 | Jiankang Yao | Uploaded new revision |
2021-02-06
|
01 | Adrian Farrel | Tag Revised I-D Needed set. Tag Awaiting Reviews cleared. |
2021-02-06
|
01 | Adrian Farrel | ISE state changed to Response to Review Needed from Finding Reviewers |
2021-01-24
|
01 | Adrian Farrel | Tag Awaiting Reviews set. |
2021-01-22
|
01 | Adrian Farrel | ISE state changed to Finding Reviewers from Submission Received |
2021-01-22
|
01 | Adrian Farrel | The Working Group has abandoned this draft, and the authors have reposted as an Individual submission prior to requesting publication on the Independent Submission stream |
2021-01-22
|
01 | Adrian Farrel | This document now replaces draft-ietf-regext-bundling-registration instead of None |
2020-12-14
|
01 | Adrian Farrel | Notification list changed to rfc-ise@rfc-editor.org because the document shepherd was set |
2020-12-14
|
01 | Adrian Farrel | Document shepherd changed to Adrian Farrel |
2020-12-14
|
01 | Adrian Farrel | ISE state changed to Submission Received |
2020-12-14
|
01 | Adrian Farrel | Intended Status changed to Informational from None |
2020-12-14
|
01 | Adrian Farrel | Stream changed to ISE from None |
2020-12-05
|
01 | Jiankang Yao | New version available: draft-yao-regext-bundling-registration-01.txt |
2020-12-05
|
01 | (System) | New version approved |
2020-12-05
|
01 | (System) | Request for posting confirmation emailed to previous authors: Jiankang Yao , Ning Kong , Linlin Zhou , Wil Tan , Jiagui Xie , Hongtao Li |
2020-12-05
|
01 | Jiankang Yao | Uploaded new revision |
2020-10-30
|
00 | Jiankang Yao | New version available: draft-yao-regext-bundling-registration-00.txt |
2020-10-30
|
00 | (System) | New version approved |
2020-10-30
|
00 | Jiankang Yao | Request for posting confirmation emailed to submitter and authors: Jiagui Xie , Linlin Zhou , Jiankang Yao , Ning Kong , Hongtao Li , Wil … Request for posting confirmation emailed to submitter and authors: Jiagui Xie , Linlin Zhou , Jiankang Yao , Ning Kong , Hongtao Li , Wil Tan |
2020-10-30
|
00 | Jiankang Yao | Uploaded new revision |