Skip to main content

Extensible Provisioning Protocol (EPP) Organization Mapping
draft-ietf-regext-org-12

Revision differences

Document history

Date Rev. By Action
2019-03-22
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-03-05
12 Antoin Verschuren Added to session: IETF-104: regext  Mon-1350
2019-02-18
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-01-29
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-01-01
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-12-27
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-12-27
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-12-26
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-12-26
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-12-26
12 (System) IANA Action state changed to Waiting on Authors
2018-12-21
12 (System) RFC Editor state changed to EDIT
2018-12-21
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-12-21
12 (System) Announcement was received by RFC Editor
2018-12-21
12 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-12-21
12 Cindy Morgan IESG has approved the document
2018-12-21
12 Cindy Morgan Closed "Approve" ballot
2018-12-21
12 Cindy Morgan Ballot approval text was generated
2018-12-21
12 Adam Roach RFC Editor Note was changed
2018-12-21
12 Adam Roach RFC Editor Note for ballot was generated
2018-12-21
12 Adam Roach RFC Editor Note for ballot was generated
2018-12-21
12 Adam Roach IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-11-29
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-11-29
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-11-29
12 Linlin Zhou New version available: draft-ietf-regext-org-12.txt
2018-11-29
12 (System) New version approved
2018-11-29
12 (System) Request for posting confirmation emailed to previous authors: James Gould , Guiqing Zhou , Linlin Zhou , Jiankang Yao , Ning Kong
2018-11-29
12 Linlin Zhou Uploaded new revision
2018-11-07
11 Eric Rescorla [Ballot comment]
Thank you for addressing my DISCUSS
2018-11-07
11 Eric Rescorla [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss
2018-11-05
11 James Galvin Added to session: IETF-103: regext  Tue-1350
2018-11-02
11 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-10-25
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-10-25
11 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-10-25
11 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-10-24
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-24
11 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-10-24
11 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-10-24
11 Eric Rescorla
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624


This DISCUSS should be easy to clear. I have noted a few points where
I do …
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624


This DISCUSS should be easy to clear. I have noted a few points where
I do not believe that the spec is sufficiently clear to implement.

DETAIL
S 3.4.

>      o  clientUpdateProhibited, serverUpdateProhibited: Requests to update
>        the object (other than to remove this status) MUST be rejected.

>      o  clientDeleteProhibited, serverDeleteProhibited: Requests to delete
>        the object MUST be rejected.

How does access control work here? If either of these values are set,
then it must be rejected?


S 4.1.2.
>      C:        res1523
>      C:     
>      C:   
>      C:    ABC-12345
>      C: 
>      C:

So I can only  one org?


S 4.1.2.

>      o  One or more  elements that contain the operational
>        status of the organization, as defined in Section 3.4.

>      o  An OPTIONAL  element that contains the identifier of
>        the parent object, as defined in Section 3.6.

It's not clear to me what's really optional here, because you say
above that it's up to the server but then you label some stuff here as
OPTIONAL
2018-10-24
11 Eric Rescorla
[Ballot comment]
S 3.2.1.
>      object.  A client can change the role of an organization object using
>      the EPP  command. …
[Ballot comment]
S 3.2.1.
>      object.  A client can change the role of an organization object using
>      the EPP  command.

>  3.2.1.  Role Type

>      An organization role MUST have a type which supports a list of

Editorial: I found this confusing. I think you want to say "MUST have
a type field. This may have any of the values listed in ...."

It's not the type that supports the list.




S 3.4.
>        rejected.

>      o  linked: The organization object has at least one active
>        association with another object.  The "linked" status is not
>        explicitly set by the client.  Servers should provide services to
>        determine existing object associations.

I'm not following this text. It is set by the server?


S 3.4.
>        has been processed for the object, but the action has not been
>        completed by the server.  Server operators can delay action
>        completion for a variety of reasons, such as to allow for human
>        review or third-party action.  A transform command that is
>        processed, but whose requested action is pending, is noted with
>        response code 1001.

Who can set this?


S 3.5.
>        association with another object.  The "linked" status is not
>        explicitly set by the client.  Servers SHOULD provide services to
>        determine existing object associations.

>      o  clientLinkProhibited, serverLinkProhibited: Requests to add new
>        links to the role MUST be rejected.

see above question about access control


S 3.6.
>      not defined for the top level reseller, namely the registrar of the
>      registry.  An N-tier reseller has a parent reseller and at least one
>      child reseller.  A reseller customer has a parent reseller and no
>      child resellers.

>      Loops MUST be prohibited.  For example: if organization A has B as

Who is this a levy on? The server MUST enforce it? What does it do if
there is an error?


S 4.1.2.
>        email address.

>      o  An OPTIONAL  element that contains the URL to the website
>        of the organization.

>      o  Zero or more OPTIONAL  elements that contain

Isn't 0 and OPTIONAL redundant?


S 4.1.2.
>        organization object.  Contact object identifiers MUST be known to
>        the server before the contact object can be associated with the
>        organization object.  The required "type" is used to represent
>        contact types.  The type values include "admin", "tech",
>        "billing", "abuse", and "custom".  The OPTIONAL "typeName"
>        attribute is used to define the name of a "custom" type.

Are duplicates allowed?


S 4.2.1.
>        status of the organization, as defined in Section 3.4.

>      o  An OPTIONAL  element that contains the identifier of
>        the parent object, as defined in Section 3.6.

>      o  Zero to two  elements that contain postal-address

These rules looks duplicative of . Is there a way to collapse
them?


S 4.2.5.
>      where at least one child element MUST be present:

>      o  An OPTIONAL  element that contains the identifier of
>        the parent object.

>      o  Zero to two  elements that contain postal-address

This also seems duplicative.
2018-10-24
11 Eric Rescorla [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla
2018-10-24
11 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-10-24
11 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-10-24
11 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-10-24
11 Alexey Melnikov
[Ballot comment]
This is a well written document, but I am concerned about missing references for various syntactic elements that you use. Having proper references …
[Ballot comment]
This is a well written document, but I am concerned about missing references for various syntactic elements that you use. Having proper references will save developers time and will improve interoperability. The same issue in at least 3 places in the document, I am mentioning the first one below.

In 4.1.1:

  o  An OPTIONAL  element that may be provided when an
      object cannot be provisioned.  If present, this element contains
      server-specific text to help explain why the object cannot be
      provisioned.  This text MUST be represented in the response
      language previously negotiated with the client; an OPTIONAL "lang"

Please either point to the Language tag RFC 5646/BCP 47 or point to another RFC which defines the "lang" attribute.

      attribute MAY be present to identify the language if the
      negotiated value is something other than the default value of
      "en"(English).

4.1.2.  EPP  Command

  o  Zero to two  elements that contain postal-address
      information.  Two elements are provided so that address
      information can be provided in both internationalized and
      localized forms; a "type" attribute is used to identify the two
      forms.  If an internationalized form (type="int") is provided,
      element content MUST be represented in a subset of Unicode in the
      range U+0020 - U+007E.  If a localized form (type="loc") is
      provided, element content MAY be represented in unrestricted UTF-
      8.  The  element contains the following child
      elements:

[snip]

        +  An  element that contains the organization's country
            code.

Please add the correct reference for country codes. I believe you want to reference alpha-2 country codes from ISO 3166.
(There are also alpha-3 country codes.)

Alternative you can just reference a section from RFC 5733.

  o  An OPTIONAL  element that contains the organization's
      email address.

Please point to specific format for email addresses (there is RFC 5321 format and RFC 5322 format. They are not identical.)
Alternative you can just reference a section from RFC 5733.

  o  An OPTIONAL  element that contains the URL to the website
      of the organization.

Please add a reference to RFC 3986 or to one of HTTP RFCs if you want to restrict this to https: or http:

One possible way of addressing all of the above is to add a few sentences with references to the "Conventions Used in This Document" section.
2018-10-24
11 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-10-23
11 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2018-10-23
11 Ben Campbell
[Ballot comment]
Hi, thanks for this work. I have some comments, both substantive and editorial:

*** Substantive Comments ***

§4.1.2: "- A
element contains the …
[Ballot comment]
Hi, thanks for this work. I have some comments, both substantive and editorial:

*** Substantive Comments ***

§4.1.2: "- A
element contains the following child elements:
+ One, two, or three OPTIONAL  elements that
contain the organization’s street address."

I take that to mean it must contain at least one. If so, I don't think OPTIONAL is appropriate; if the elements are optional, they can be left out. simply saying it contains "1, 2, or 3" would be more appropriate.

§9: The org element can contain contact information, possibly including personally identifiable information of individuals. Doesn’t this have privacy implications that should be discussed here or in a privacy considerations section?

*** Editorial Comments ***

- General:

I'm a little confused by the split in material between draft-ietf-regext-org and draft-ietf-regext-org-ext, especially how the command mapping and related info seems to span both documents. It seems a bit reader-unfriendly. But it's late enough in the process that it's probably not worth changing.

§1, paragraph 1: Please expand EPP on first use in the body. (You do expand it on the 2nd use in the next paragraph :-) )

§2, 3rd paragraph:  I know we are not consistent about this, but I find the word “conforming” to be a red flag. Standards track RFCs should be about interoperability, not conformance. I suggest striking all after “presented”.

§3.2.1: Plural disagreement between “roles and “type” in the second sentence.

§3.3: Plural disagreements between "contacts" and "identifier"

§3.4, 5th paragraph from end: "Organization MUST have only one of these
statuses set"
Please avoid constructions of the form "MUST...only". They can be ambiguous. Please consider something to the effect of "MUST NOT have more than one" or "MUST have exactly one". (Same for the "MAY...only" in the next paragraph.)

§4 and subsections: - The text is inconsistent in the use of OPTIONAL for optional elements. Many are labeled as optional, but some with descriptions along the lines of "zero or more" are not labeled OPTIONAL when they clearly are. I don't have a strong opinion which way to go, but please be consistent.

§4.1.1:
- "When a  command has been processed successfully, the EPP
element MUST contain a child  element"
That MUST seems more like a statement of fact. (This pattern occurs several times.)
- "an OPTIONAL "lang" attribute MAY be present"
OPTIONAL and MAY are redundant.

- Command mappings in general: The text is inconsistent in the use of OPTIONAL for optional elements. Many are labeled as optional, but some with descriptions along the lines of "zero or more" are not labeled OPTIONAL when they clearly are. I don't have a strong opinion which way to go, but please be consistent.
2018-10-23
11 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-10-23
11 Benjamin Kaduk
[Ballot comment]
Some of the element descriptions (e.g., ) appear to be
duplicated in several places and are also rather long in prose form.  Is …
[Ballot comment]
Some of the element descriptions (e.g., ) appear to be
duplicated in several places and are also rather long in prose form.  Is
there value in attempting to consolidate the structural definition to a
single place in the document and just refer to that structure from the
places where it can appear?

Section 1

  There are many entities, such as registrars, resellers, DNS service
  operators, or privacy proxies involved in the domain registration
  business.  These kind of entities have not been formally defined as
  an object in EPP which will be specified as "organization" in this
  document.

nit: run-on sentence.  I suggest:
  These kind of entities have not been formally defined as having
  an object in EPP. This document provides a way to specify them as
  "organization" entities.

Section 2

  The XML namespace prefix "org" is used, but implementations MUST NOT
  depend on it and instead employ a proper namespace-aware XML parser
  and serializer to interpret and output the XML documents.

I suggest mentioning more explicitly that "org" is used in the examples as
shorthand for the full namespace "urn:ietf:params:xml:ns:epp:org-1.0";
draft-ietf-regext-allocation-token would be a fine example to look at.

Section 3.4

  Status values that can be added or removed by a client are prefixed
  with "client".  Corresponding status values that can be added or
  removed by a server are prefixed with "server".  The "hold" and
  "terminated" status values are server-managed when the organization
  has no parent identifier [Section 3.6] and otherwise MAY be client-
  managed based on server policy.

The list/descriptions that follows shows several that don't start with
"client"/"server", including some not mentioned here.  Are we supposed to
assume that these "unprefixed" values are also server-managed?

  o  ok: This is the normal status value for an object that has no
      pending operations or prohibitions.  This value is set and removed
      by the server as other status values are added or removed.

I guess this is intended to be parsed as "(pending operations) or
(prohibitions)", but could also be parsed as "pending (operations or
prohibitions)".  Perhaps "operations pending or active prohibitions" is
less prone to misreading.

In general, the sort of "all combinations are permitted, except for these
restrictions" approach taken here can lead to some non-sensical
combinations, if insufficient care is taken by the document authors.  I did
not attempt to validate all possible combinations, but do note that (e.g.)
we make statements about "linked" in combination with "ok" and
"client/serverLinkProhibited", but not about "linked" in combination with
"terminated" or several other status values.  The first of those cases
serves as a limitation on "ok", and the second would seem to be intended to
clarify that an apparent conflict of status is permissible, and so it may
well be okay to leave as the default ("everything goes") for other
combinations, but I hope that the WG has done a careful analysis here.
It may also be useful to list what considerations were used in this
analysis, in case there is ever a need to add a new status value (in which
case the analyses would need to be performed anew for the added value(s)).

Section 3.4

(Same comment as above re "pending operations or prohibitions")

Section 3.6

  Take a reseller organization, for example, the parent identifier is
  not defined for the top level reseller, namely the registrar of the
  registry.  [...]

nit: this also looks like a run-on sentence; I'd suggest something like
"The case of reseller organizations provides an example.  The parent
identifier is not defined [...]"

  Loops MUST be prohibited.  For example: if organization A has B as
  its parent identifier, organization B should not have organization A
  as its parent identifier.  The same is true for larger loops
  involving three or more organizations.

I'd suggest s/should not/cannot/

Section 4.1.1

  In addition to the standard EPP command elements, the  command
  MUST contain an  element.  This element or its ancestor
  element MUST identify the organization namespace.  [...]

"the organization namespace" is perhaps ambiguous; am I correct in
inferring that this refers to the full "urn:ietf:params:xml:ns:epp:org-1.0"
namespace value as assigned to the "org" short name?  (I'll refrain from
repeating this comment every time it applies.)

Section 4.1.2

The  restrictions seem somewhat contrived/artificially
restricted; for example, there are postal addresses in the US with no
associated city.  Whether an organization would want to use such an address
as its contact location is another question, but I don't have a clear model
of what sort of constraints are intended to be applied by this element.

Section 4.2.1

Just to check my understanding, the  contains only a short
list of fields because the server is required to either respect the various
, , etc. in the  request or to return
an error?  That is, the client would not need to immediately perform an
query to confirm the status of the organization object at the
server.

Section 4.2.2

Is there value in an example of the 2305-error response?

Section 4.2.5

The elements in / vs.  seem to be disjoint sets;
what factors went into deciding to split them this way?

Section 4.3

            The status of the corresponding object MUST clearly reflect
  processing of the pending action.  [...]

It's not entirely clear how this sentence is to be interpreted.  From
context, I assume that the intent is that  queries and similar must
report that the appropriate pendingFoo status values, but a literal reading
would seem to have this sentence be a requirement that the server change
what it reports for the object status, once the action is actually taken.
(Which is also something desired, but arguably already required by other
text.)

  The status of the organization object after returning this response
  MUST include "pendingCreate".  The server operator reviews the
  request offline, and informs the client of the outcome of the review
  either by queuing a service message for retrieval via the
  command or by using an out-of-band mechanism to inform the client of
  the request.

I don't think the "either" is appropriate; the earlier text *requires* the
service message, and allows for additional optional notification
mechanisms.

(side question: what's the mnemonic for "pan" in "panData"?  "pending
action"?  Ah, the full schema suggests "pending action notification".
Also, why is the top-level a "pan" prefix but the children just "pa"?)

Section 7.3.1

  Registrant Name: For Standards Track RFCs, state "IESG".  For others,
  give the name of the responsible party.

Just to clarify, is the intended behavior for non-standards-track
IETF-stream RFCs that the registrant is one of the RFC authors?  I could
see a case that "IESG" would work for all IETF-stream documents, not just
standards-track ones.

  Registrant Contact Information: an email address, postal address, or
  some other information to be used to contact the registrant.

Perhaps a side note, but postal address in particular has come up
frequently in GDPR discussions, with the question of whether it is either
needed or useful.

Section 9

This document is pretty boring from the security perspective (to be clear:
that is a good thing!).  The only thing that came to mind is that in one of
the examples, we show the client asking for s of res1523, re1523,
and just 1523.  Only "re1523" was in use, indicating that the other two
would be free for new allcations.  In some contexts this kind of "very
similar looking" identifier can be problematic, especially when a human is
called upon to verify or compare the value(s).  From what I understand of
EPP usage, that doesn't seem likely to be a concern here, but I mention it
in case my understanding is incorrect or incomplete.
2018-10-23
11 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-10-23
11 Stewart Bryant Request for Telechat review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list.
2018-10-19
11 Jürgen Schönwälder Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jürgen Schönwälder. Sent review to list.
2018-10-11
11 Jean Mahoney Request for Telechat review by GENART is assigned to Stewart Bryant
2018-10-11
11 Jean Mahoney Request for Telechat review by GENART is assigned to Stewart Bryant
2018-10-10
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-10-10
11 Linlin Zhou New version available: draft-ietf-regext-org-11.txt
2018-10-10
11 (System) New version approved
2018-10-10
11 (System) Request for posting confirmation emailed to previous authors: James Gould , Guiqing Zhou , Linlin Zhou , Jiankang Yao , Ning Kong
2018-10-10
11 Linlin Zhou Uploaded new revision
2018-10-08
10 Cindy Morgan Placed on agenda for telechat - 2018-10-25
2018-10-08
10 Adam Roach IESG state changed to IESG Evaluation from Waiting for Writeup
2018-10-08
10 Adam Roach Ballot has been issued
2018-10-08
10 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2018-10-08
10 Adam Roach Created "Approve" ballot
2018-10-08
10 Adam Roach Ballot writeup was changed
2018-10-08
10 Stewart Bryant Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Stewart Bryant. Sent review to list.
2018-10-08
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-10-05
10 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-10-05
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-org-10. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-org-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new registration will be made as follows:

ID: epp:org-1.0
URI: urn:ietf:params:xml:ns:epp:org-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the schema registry also on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new registration will be made as follows:

ID: epp:org-1.0
URI: urn:ietf:params:xml:schema:epp:org-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this request also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Extensions for the Extensible Provisioning Protocol (EPP) registry located at:

https://www.iana.org/assignments/epp-extensions/

a single, new registration will be made as follows:

Name of Extension: Extensible Provisioning Protocol (EPP) Organization Mapping
Document Status: [ To be taken from the published document ]
Reference: [ RFC-to-be ]
Registrant: IESG [ iesg@ietf.org ]
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None

As this request also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, a new registry is to be created called the EPP Organization Role Values registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is to be managed via Expert Review as defined in RFC 8126.

There are initial values in the new registry as follows:

Value: registrar
Description: The entity object instance represents the authority responsible for the registration in the registry.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org
Referene: [ RFC-to-be ]

Value: reseller
Description: The entity object instance represents a third party through which the registration was conducted (i.e., not the registry or registrar).
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org
Referene: [ RFC-to-be ]

Value: privacyproxy
Description: The entity object instance represents a third-party who could help to register a domain without exposing the registrants' private information.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org
Referene: [ RFC-to-be ]

Value: dns-operator
Description: The entity object instance represents a third-party DNS operator that maintains the name servers and zone data on behalf of a registrant.

Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org
Referene: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-10-04
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2018-10-04
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2018-10-04
10 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Charlie Kaufman.
2018-09-27
10 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2018-09-27
10 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2018-09-27
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2018-09-27
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2018-09-24
10 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-09-24
10 Amy Vezza
The following Last Call announcement was sent out (ends 2018-10-08):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, draft-ietf-regext-org@ietf.org, regext-chairs@ietf.org, pieter.vandepitte@dnsbelgium.be, Pieter …
The following Last Call announcement was sent out (ends 2018-10-08):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, draft-ietf-regext-org@ietf.org, regext-chairs@ietf.org, pieter.vandepitte@dnsbelgium.be, Pieter Vandepitte , regext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Extensible Provisioning Protocol (EPP) Organization Mapping) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Extensible Provisioning
Protocol (EPP) Organization Mapping'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-10-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes an Extensible Provisioning Protocol (EPP)
  mapping for provisioning and management of organization objects
  stored in a shared central repository.  Specified in Extensible
  Markup Language (XML), this extended mapping is applied to provide
  additional features required for the provisioning of organizations.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-org/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-regext-org/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc2718: Guidelines for new URL Schemes (Informational - IETF stream)



2018-09-24
10 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-09-24
10 Amy Vezza Last call announcement was changed
2018-09-23
10 Adam Roach Last call was requested
2018-09-23
10 Adam Roach Last call announcement was generated
2018-09-23
10 Adam Roach Ballot approval text was generated
2018-09-23
10 Adam Roach Ballot writeup was generated
2018-09-23
10 Adam Roach IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2018-08-23
10 Linlin Zhou New version available: draft-ietf-regext-org-10.txt
2018-08-23
10 (System) New version approved
2018-08-23
10 (System) Request for posting confirmation emailed to previous authors: James Gould , Guiqing Zhou , Linlin Zhou , Jiankang Yao , Ning Kong
2018-08-23
10 Linlin Zhou Uploaded new revision
2018-08-19
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-08-19
09 Linlin Zhou New version available: draft-ietf-regext-org-09.txt
2018-08-19
09 (System) New version approved
2018-08-19
09 (System) Request for posting confirmation emailed to previous authors: XiaoDong Lee , Linlin Zhou , regext-chairs@ietf.org, Guiqing Zhou , James Gould , Ning Kong
2018-08-19
09 Linlin Zhou Uploaded new revision
2018-08-10
08 Adam Roach Awaiting document changes reflecting outcome of discussion of AD review.
2018-08-10
08 Adam Roach IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::Point Raised - writeup needed
2018-07-26
08 Adam Roach Waiting on response from WG/authors about blocking issue identified in AD review: https://mailarchive.ietf.org/arch/msg/regext/olUclQRuEydB5q9DICVkyvhNOaU
2018-07-26
08 Adam Roach IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation
2018-07-26
08 Adam Roach IESG state changed to AD Evaluation from Publication Requested
2018-07-13
08 Antoin Verschuren
This is a write-up for the draft-ietf-regext-org-08 and draft-ietf-regext-org-ext-07
documents as they belong together and were reviewed and treated as one work item.

1. Summary …
This is a write-up for the draft-ietf-regext-org-08 and draft-ietf-regext-org-ext-07
documents as they belong together and were reviewed and treated as one work item.

1. Summary
 
The document shepherd is Pieter Vandepitte, pieter.vandepitte@dnsbelgium.be
The responsible Area Director is Adam Roach, adam@nostrum.com
 
The documents are submitted for consideration as a Proposed Standard:
they have received community review and are of interest to multiple parties as
they cover a basic need among domain name registrars and registries.

Original work for the documents started as a need to register resellers for
domain names to be represented in Whois and RDAP. The working group concluded
that the objective was too limited to justify the introduction of a new EPP
object, as they remarked that future organization roles other than resellers
would each require their own EPP object. Furthermore, if each role would be
represented by its own object, it would lead to a proliferation of different
objects, some of them representing the same organization. This would make it
hard to maintain and potentially lead to errors. Therefore, these Internet drafts
define an organization object which can be assigned multiple roles, and
role types are standardized in an IANA registry to prevent a proliferation of role
types across registries.

The draft-ietf-regext-org-08 document describes an
Extensible Provisioning Protocol (EPP) mapping for provisioning and management
of organization objects stored in a shared central repository.  Specified in
Extensible Markup Language (XML), this extended mapping is applied to provide
additional features required for the provisioning of organizations.
 
The draft-ietf-regext-org-ext-07 document describes an extension to EPP object
mappings, which is designed to support assigning an organization to any existing
object (domain, host, contact) as well as any future objects.

Both documents are an extension of the core EPP specifications
in STD 69. They use the framework outlined in RFC 3735
"Guidelines for Extending the Extensible Provisioning Protocol (EPP)",
to extend some EPP operations by exchanging a new piece of information,
the organization object. 
 
Both documents written with the usual set of sections in the expected order like
other documents extending EPP, in order to make its reading simpler for future
implementors.
 
The documents follow the RFC style described in RFC 7322 and do not introduce
new security considerations besides the new existing in the core EPP RFCs.
 
All references have been identified as either normative or informative.
There are no normative references on documents with unclear state and no
downward normative references.
 
2. Review and Consensus
 
Both documents have been discussed on the mailing lists and various IETF meetings
of the regext working group. The authors have addressed all comments and changes
have been incorporated in the documents. The documents have been updated several
times during the WGLC due to several thorough reviews.
 
Verisign and CNNIC have working implementations of the specifications and at least
2 other Registry operators have plans or are interested in implementing the
specifications.
 
3. Intellectual Property
 
The author has confirmed following BCP 78 and BCP 79 in the document header.
No IPR disclosures have been submitted for the documents.
 
4. Other Points
 
All EPP XML examples have been validated against the XML schema provided
in the drafts by the Document Shepherd.
 
Each document requests IANA to register a new XML namespace URI and the
XML schemas for the namespace definitions. Additionally it requests IANA
to insert the document in the EPP Extension Registry, per RFC 7451.
 
The draft-ietf-regext-org-08 document requests IANA to create a new protocol registry to
manage organization roles.  All requirements for such a request have been
met.  A detailed review by IANA is suggested.
2018-07-13
08 Antoin Verschuren Responsible AD changed to Adam Roach
2018-07-13
08 Antoin Verschuren IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-07-13
08 Antoin Verschuren IESG state changed to Publication Requested
2018-07-13
08 Antoin Verschuren IESG process started in state Publication Requested
2018-07-02
08 Pieter Vandepitte Changed document writeup
2018-07-01
08 Linlin Zhou New version available: draft-ietf-regext-org-08.txt
2018-07-01
08 (System) New version approved
2018-07-01
08 (System) Request for posting confirmation emailed to previous authors: Guiqing Zhou , Ning Kong , Linlin Zhou , XiaoDong Lee , James Gould
2018-07-01
08 Linlin Zhou Uploaded new revision
2018-06-14
07 Linlin Zhou New version available: draft-ietf-regext-org-07.txt
2018-06-14
07 (System) New version approved
2018-06-14
07 (System) Request for posting confirmation emailed to previous authors: Guiqing Zhou , Ning Kong , Linlin Zhou , XiaoDong Lee , James Gould
2018-06-14
07 Linlin Zhou Uploaded new revision
2018-05-11
06 Antoin Verschuren IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-05-11
06 Antoin Verschuren Notification list changed to Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be>
2018-05-11
06 Antoin Verschuren Document shepherd changed to Pieter Vandepitte
2018-05-08
06 Linlin Zhou New version available: draft-ietf-regext-org-06.txt
2018-05-08
06 (System) New version approved
2018-05-08
06 (System) Request for posting confirmation emailed to previous authors: Guiqing Zhou , Ning Kong , Linlin Zhou , XiaoDong Lee , James Gould
2018-05-08
06 Linlin Zhou Uploaded new revision
2018-05-07
05 Linlin Zhou New version available: draft-ietf-regext-org-05.txt
2018-05-07
05 (System) New version approved
2018-05-07
05 (System) Request for posting confirmation emailed to previous authors: Guiqing Zhou , Ning Kong , Linlin Zhou , XiaoDong Lee , James Gould
2018-05-07
05 Linlin Zhou Uploaded new revision
2018-05-03
04 Linlin Zhou New version available: draft-ietf-regext-org-04.txt
2018-05-03
04 (System) New version approved
2018-05-03
04 (System) Request for posting confirmation emailed to previous authors: Guiqing Zhou , Ning Kong , Linlin Zhou , XiaoDong Lee , James Gould
2018-05-03
04 Linlin Zhou Uploaded new revision
2018-04-27
03 Linlin Zhou New version available: draft-ietf-regext-org-03.txt
2018-04-27
03 (System) New version approved
2018-04-27
03 (System) Request for posting confirmation emailed to previous authors: Guiqing Zhou , Ning Kong , Linlin Zhou , XiaoDong Lee , James Gould
2018-04-27
03 Linlin Zhou Uploaded new revision
2018-04-13
02 Antoin Verschuren IETF WG state changed to In WG Last Call from WG Document
2018-02-27
02 Linlin Zhou New version available: draft-ietf-regext-org-02.txt
2018-02-27
02 (System) New version approved
2018-02-27
02 (System) Request for posting confirmation emailed to previous authors: Guiqing Zhou , Ning Kong , Linlin Zhou , XiaoDong Lee , James Gould
2018-02-27
02 Linlin Zhou Uploaded new revision
2017-12-04
01 Linlin Zhou New version available: draft-ietf-regext-org-01.txt
2017-12-04
01 (System) New version approved
2017-12-04
01 (System) Request for posting confirmation emailed to previous authors: Guiqing Zhou , Ning Kong , Linlin Zhou , XiaoDong Lee , James Gould
2017-12-04
01 Linlin Zhou Uploaded new revision
2017-12-04
00 (System) Document has expired
2017-06-02
00 Antoin Verschuren Changed consensus to Yes from Unknown
2017-06-02
00 Antoin Verschuren Intended Status changed to Proposed Standard from None
2017-06-02
00 Antoin Verschuren A new more generalized organization aproach replaces the reseller approach.
2017-06-02
00 Antoin Verschuren This document now replaces draft-ietf-regext-reseller instead of None
2017-06-02
00 Linlin Zhou New version available: draft-ietf-regext-org-00.txt
2017-06-02
00 (System) WG -00 approved
2017-05-11
00 Linlin Zhou Set submitter to "Linlin Zhou ", replaces to (none) and sent approval email to group chairs: regext-chairs@ietf.org
2017-05-11
00 Linlin Zhou Uploaded new revision