From nobody Mon Sep 1 20:16:32 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE5F1A6FBB for ; Mon, 1 Sep 2014 20:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.959 X-Spam-Level: X-Spam-Status: No, score=-4.959 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry-xWPJQltJV for ; Mon, 1 Sep 2014 20:16:26 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80C71A6FAB for ; Mon, 1 Sep 2014 20:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1409627786; x=1441163786; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=xT3ZFiaQvgpLfx5X+YtZAMVrzhVonfHskGXNLmG29Gk=; b=BEE48/Y30HczZ2Dst+P2tPIHKN/8+Cn99qDbQhyCtdvqGcM28f3JW3ul hiYvfnDLXLjk1ensvjuZQtRPo38iPWs3acm3mss9mGW2dPiEMKTtm3IIX DV0fvL6FotjCV989FozQ/s8ueTs4cBp7RdQMAclxPa4yBmOwYtyuIfnCS g=; X-IronPort-AV: E=McAfee;i="5600,1067,7548"; a="154227362" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 01 Sep 2014 20:16:26 -0700 X-IronPort-AV: E=Sophos;i="5.04,446,1406617200"; d="scan'208";a="796596467" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Sep 2014 20:16:27 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 1 Sep 2014 20:16:04 -0700 Message-ID: <54053671.9030409@qti.qualcomm.com> Date: Mon, 1 Sep 2014 22:16:01 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/AXpGyEkY6gP-ehxEsBcw-8e4YLo Subject: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 03:16:29 -0000 At long last, my AD Review of draft-ietf-eppext-reg-07. My apologies for the delay. First, please don't worry about the length of this message. As long as it is, there's nothing earth shattering in here. The number of changes I suggest are actually pretty small, but I wanted to give you a good explanation of why I suggested them. So, first an overall comment: My understanding is that right now, caveat the initial registrations in section 4 (more on them in a moment), the things that go into this registry are being put there for "informational" purposes. That is, it's a place to document the way things are being done now, but not indicating any form of endorsement for one way over the other. However, my understanding of the purpose of this registry is so that the EPP community can, over the long term, harmonize extensions. That is, we want folks to register these things so that folks who are developing extensions might look and see, "Oh, that one does what I need; I should just use that one." Furthermore, over time, folks might decide, "Hey, these three extensions do the same thing; let's pick one way of doing it." If the community agrees, they can "standardize" that way of doing things. That will make life easier on registrars (and everyone for that matter) so that folks won't have to implement the same thing multiple different ways. I would expect that the way that would happen would be to create a IETF Standards Track RFC for those extensions that everyone agrees are "*the* way to do this thing". So it seems to me that, while most of the things expected to be registered here are strictly "informational" documents (mostly outside of the IETF), we might want to have an extra column in the registry to indicate the standards status of the registry entry so that people can see if there is a particular item that is standard. It also seems to me that if a registration is an IETF Standards Track document, that should indicate that it has already gotten sufficient review and therefore the Designated Experts don't need to. So my suggestions are to address this are: 1. In section 3.1.1, add: "If the specification for the registration is an IETF Standards Track document, no review is required by the Designated Expert." 2. In section 3.2.1: OLD Registrant Name and Email Address: The case-insensitive name and email address of the person that is responsible for managing the registry entry. NEW 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 " (I don't think you need to specify "case-insensitive" above, especially because it doesn't make sense in some languages.) Also add: Document Status: The document status ("Informational", "Standards Track", etc.) of the specification document. For documents that are not RFCs, this will always be "Informational". So, getting back to the initial 4 registrations (RFCs 3915, 4114, 5076, and 5910): Each of those is currently on the Standards Track. I would presume that they would each go into the registry as "Document Status: Standards Track", presuming that they've already gotten community consensus that they are "*the* way to do this thing". (Otherwise, they probably shouldn't have been on the Standards Track in the first place, in which case we should probably have a discussion about what to do.) Does all that make sense? --- Other more minor comments: (Overall editorial note: Generally, I find the use of the 2119 language in this document unnecessary. We're supposed to use those terms where interoperability is needed, and here they just seem a bit overdone. Also, I don't think that you need to say things like "'Any' or 'ANY'", since if you're going to allow them to be case-insensitive, "AnY" and "aNY" and all the other silly ones could also be used. And that said, I don't think you need to specify case-insensitive; it's a form that will be handled by humans. Just give one example, either in title case or upper case, and be done with it.) 3.1, first paragraph, I suggest: NEW This registry uses the "Specification Required" policy described in RFC 5226 [RFC5226]. An English language version of the extension specification will appear in the registry, though non-English versions of the specification can also be provided. Note that Section 2.1 of RFC 3735 [RFC3735] provides specific guidelines for documenting EPP extensions. 3.2.1: OLD Specification Location: A URL [RFC3986] that describes the location of the specification. I suspect that won't satisfy IANA, as they generally want a stable reference, though they will take a URL if need be. 5226 says: Specification Required - Values and their meanings must be documented in a permanent and readily available public specification [...] The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. How about instead simply saying: NEW Reference: A reference to the specification of this extension. This could be an RFC number or some other pointer to the document defining the extension. OLD TLDs: A case-insensitive text string description of the top-level domain (or domains) for which the extension has been specified. "Any" or "ANY" MUST be used if the extension is not associated with a specific top-level domain. Multiple TLDs SHOULD be specified as a list of domain names separated by commas, e.g. ".com, .net". Internationalized Domain Name (IDN) TLDs should be specified in A-label [RFC5890] format. "A case-insensitive text string description of the top-level domain" seems weird. First, if we're using A-Labels, we already know they're case-insensitive. Second, the string *is* the domain name, isn't it? Finally, you should be clear to include the "." at the beginning. How about instead: NEW TLDs: A text string containing the top-level domain name (or domains names), including the preceding ".", for which the extension has been specified (e.g., ".org"). If there are multiple TLDs, they are given as a list of domain names separated by commas, (e.g. ".com, .net"). Internationalized Domain Name (IDN) TLDs should be specified in A-label [RFC5890] format. If the extension is not associated with a specific top-level domain, the case-insensitive text string "ANY" can be used to indicate that. OLD IPR Disclosure: Either "None", "NONE", or a URL that describes the location of an IPR disclosure document. Depending on the type of specification the IPR disclosure MAY be filed with the IETF in accordance with RFC 3979 [RFC3979] as updated by RFC 4879 [RFC4879]. Non-IETF IPR disclosures MUST clearly identify the claimed intellectual property rights and terms of use. "None" or "NONE" indicates that the extension is freely available for use with no claimed intellectual property rights. That last sentence gave me heartburn. Just because nobody has made a disclosure does not mean something is "freely available for use with no claimed IPR." How about this: NEW IPR Disclosure: A pointer to any IPR disclosure document(s) related to this extension, or "None" if there are no such disclosures. This can be an IPR disclosure filed with the IETF in accordance with RFC 3979 [RFC3979] as updated by RFC 4879 [RFC4879] if the extension is part of an IETF Contribution, or can be other IPR disclosures documents identifying the claimed intellectual property rights and terms of use for extensions that are not part of an IETF Contribution. OLD Status: Either "Active", "ACTIVE", "Inactive", or "INACTIVE". NEW Status: Either "ACTIVE" or "INACTIVE". OLD Notes: Either "None", "NONE", or other text NEW Notes: Either "NONE" or other text Change 3.2.2 to agree with the above (and eliminate the MUST and MAY in there too). 3.2.3: OLD Each registration form sent to IANA MUST contain a single record for incorporation into the registry. The form will be sent via email to by the extension registrant. It MUST have a subject... NEW Send each registration form to IANA with a single record for incorporation into the registry. The form will be sent via email to by the extension registrant, and will have a subject... 3.2.4: OLD All changes to existing registry entries MUST be documented with text in the "Notes" field of the registration form. Under normal circumstances registry entries MAY only be updated by the registrant. If the registrant becomes unavailable or otherwise unresponsive, the designated expert MAY submit a registration form to IANA to update the registrant information. Entries MAY change state from "Active"... NEW When submitting changes to existing registry entries, include text in the "Notes" field of the registration form describing the change. Under normal circumstances, registry entries are only be updated by the registrant. If the registrant becomes unavailable or otherwise unresponsive, the designated expert can submit a registration form to IANA to update the registrant information. Entries can change state from "Active"... That's it. Let me know what you think. I'll mark the document in the tracker as "Revised I-D Needed". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Sep 2 05:45:32 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAA21A02F9 for ; Tue, 2 Sep 2014 05:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay8-X5pihzgb for ; Tue, 2 Sep 2014 05:45:28 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08CCA1A02F4 for ; Tue, 2 Sep 2014 05:45:27 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKVAW75piaugSplc6KaA+1gSAKKt7VDLN3@postini.com; Tue, 02 Sep 2014 05:45:27 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s82CjPHV013403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 08:45:26 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 2 Sep 2014 08:45:24 -0400 From: "Gould, James" To: Pete Resnick , "eppext@ietf.org" Thread-Topic: [eppext] AD Review of draft-ietf-eppext-reg-07 Thread-Index: AQHPxlxNKaP1j2RJk0yawK6cpjlKFZvtxWqK Date: Tue, 2 Sep 2014 12:45:24 +0000 Message-ID: References: <54053671.9030409@qti.qualcomm.com> In-Reply-To: <54053671.9030409@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/hBrUG1B_eFcQFjbSPWHVELsZftY Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 12:45:31 -0000 Pete,=0A= =0A= I have a few questions related to your suggestion in adding a new "Document= Status" element. =0A= =0A= 1. What should the value be for a document that is intended to be Standards= Track? I'm assuming that we would want to register drafts that are intend= ed for Standards Track as they go through the process. =0A= 2. Will this get confused with the possible values defined in RFC 2026 or s= hould we use the values as defined in RFC 2026? =0A= 3. Couldn't the official document status be determined by following the Spe= cification Location in the case of an IETF document? For those documents t= hat are not IETF documents, then following the Specification Location would= not provide a document status. =0A= =0A= Thanks,=0A= =0A= Jim=0A= =0A= ________________________________________=0A= From: EppExt [eppext-bounces@ietf.org] on behalf of Pete Resnick [presnick@= qti.qualcomm.com]=0A= Sent: Monday, September 01, 2014 11:16 PM=0A= To: eppext@ietf.org=0A= Subject: [eppext] AD Review of draft-ietf-eppext-reg-07=0A= =0A= At long last, my AD Review of draft-ietf-eppext-reg-07. My apologies for=0A= the delay.=0A= =0A= First, please don't worry about the length of this message. As long as=0A= it is, there's nothing earth shattering in here. The number of changes I=0A= suggest are actually pretty small, but I wanted to give you a good=0A= explanation of why I suggested them.=0A= =0A= So, first an overall comment:=0A= =0A= My understanding is that right now, caveat the initial registrations in=0A= section 4 (more on them in a moment), the things that go into this=0A= registry are being put there for "informational" purposes. That is, it's=0A= a place to document the way things are being done now, but not=0A= indicating any form of endorsement for one way over the other. However,=0A= my understanding of the purpose of this registry is so that the EPP=0A= community can, over the long term, harmonize extensions. That is, we=0A= want folks to register these things so that folks who are developing=0A= extensions might look and see, "Oh, that one does what I need; I should=0A= just use that one." Furthermore, over time, folks might decide, "Hey,=0A= these three extensions do the same thing; let's pick one way of doing=0A= it." If the community agrees, they can "standardize" that way of doing=0A= things. That will make life easier on registrars (and everyone for that=0A= matter) so that folks won't have to implement the same thing multiple=0A= different ways. I would expect that the way that would happen would be=0A= to create a IETF Standards Track RFC for those extensions that everyone=0A= agrees are "*the* way to do this thing".=0A= =0A= So it seems to me that, while most of the things expected to be=0A= registered here are strictly "informational" documents (mostly outside=0A= of the IETF), we might want to have an extra column in the registry to=0A= indicate the standards status of the registry entry so that people can=0A= see if there is a particular item that is standard. It also seems to me=0A= that if a registration is an IETF Standards Track document, that should=0A= indicate that it has already gotten sufficient review and therefore the=0A= Designated Experts don't need to.=0A= =0A= So my suggestions are to address this are:=0A= =0A= 1. In section 3.1.1, add: "If the specification for the registration is=0A= an IETF Standards Track document, no review is required by the=0A= Designated Expert."=0A= =0A= 2. In section 3.2.1:=0A= =0A= OLD=0A= Registrant Name and Email Address: The case-insensitive name and=0A= email address of the person that is responsible for managing the=0A= registry entry.=0A= NEW=0A= Registrant Name and Email Address: The name and email address of the=0A= person that is responsible for managing the registry entry. If the=0A= registration is of an IETF Standards Track document, this can simply=0A= be listed as "IESG "=0A= =0A= (I don't think you need to specify "case-insensitive" above, especially=0A= because it doesn't make sense in some languages.)=0A= =0A= Also add:=0A= =0A= Document Status: The document status ("Informational", "Standards=0A= Track", etc.) of the specification document. For documents that are=0A= not RFCs, this will always be "Informational".=0A= =0A= So, getting back to the initial 4 registrations (RFCs 3915, 4114, 5076,=0A= and 5910): Each of those is currently on the Standards Track. I would=0A= presume that they would each go into the registry as "Document Status:=0A= Standards Track", presuming that they've already gotten community=0A= consensus that they are "*the* way to do this thing". (Otherwise, they=0A= probably shouldn't have been on the Standards Track in the first place,=0A= in which case we should probably have a discussion about what to do.)=0A= =0A= Does all that make sense?=0A= =0A= ---=0A= =0A= Other more minor comments:=0A= =0A= (Overall editorial note: Generally, I find the use of the 2119 language=0A= in this document unnecessary. We're supposed to use those terms where=0A= interoperability is needed, and here they just seem a bit overdone.=0A= Also, I don't think that you need to say things like "'Any' or 'ANY'",=0A= since if you're going to allow them to be case-insensitive, "AnY" and=0A= "aNY" and all the other silly ones could also be used. And that said, I=0A= don't think you need to specify case-insensitive; it's a form that will=0A= be handled by humans. Just give one example, either in title case or=0A= upper case, and be done with it.)=0A= =0A= 3.1, first paragraph, I suggest:=0A= =0A= NEW=0A= This registry uses the "Specification Required" policy described in=0A= RFC 5226 [RFC5226]. An English language version of the extension=0A= specification will appear in the registry, though non-English=0A= versions of the specification can also be provided. Note that=0A= Section 2.1 of RFC 3735 [RFC3735] provides specific guidelines for=0A= documenting EPP extensions.=0A= =0A= 3.2.1:=0A= =0A= OLD=0A= Specification Location: A URL [RFC3986] that describes the location=0A= of the specification.=0A= =0A= I suspect that won't satisfy IANA, as they generally want a stable=0A= reference, though they will take a URL if need be. 5226 says:=0A= =0A= Specification Required - Values and their meanings must be=0A= documented in a permanent and readily available public=0A= specification [...] The intention behind=0A= "permanent and readily available" is that a document can=0A= reasonably be expected to be findable and retrievable long=0A= after IANA assignment of the requested value.=0A= =0A= How about instead simply saying:=0A= =0A= NEW=0A= Reference: A reference to the specification of this extension. This=0A= could be an RFC number or some other pointer to the document defining= =0A= the extension.=0A= =0A= OLD=0A= TLDs: A case-insensitive text string description of the top-level=0A= domain (or domains) for which the extension has been specified.=0A= "Any" or "ANY" MUST be used if the extension is not associated with a= =0A= specific top-level domain. Multiple TLDs SHOULD be specified as a=0A= list of domain names separated by commas, e.g. ".com, .net".=0A= Internationalized Domain Name (IDN) TLDs should be specified in=0A= A-label [RFC5890] format.=0A= =0A= "A case-insensitive text string description of the top-level domain"=0A= seems weird. First, if we're using A-Labels, we already know they're=0A= case-insensitive. Second, the string *is* the domain name, isn't it?=0A= Finally, you should be clear to include the "." at the beginning. How=0A= about instead:=0A= =0A= NEW=0A= TLDs: A text string containing the top-level domain name (or domains=0A= names), including the preceding ".", for which the extension has been= =0A= specified (e.g., ".org"). If there are multiple TLDs, they are given=0A= as a list of domain names separated by commas, (e.g. ".com, .net").=0A= Internationalized Domain Name (IDN) TLDs should be specified in=0A= A-label [RFC5890] format. If the extension is not associated with a=0A= specific top-level domain, the case-insensitive text string "ANY" can= =0A= be used to indicate that.=0A= =0A= OLD=0A= IPR Disclosure: Either "None", "NONE", or a URL that describes the=0A= location of an IPR disclosure document. Depending on the type of=0A= specification the IPR disclosure MAY be filed with the IETF in=0A= accordance with RFC 3979 [RFC3979] as updated by RFC 4879 [RFC4879].=0A= Non-IETF IPR disclosures MUST clearly identify the claimed=0A= intellectual property rights and terms of use. "None" or "NONE"=0A= indicates that the extension is freely available for use with no=0A= claimed intellectual property rights.=0A= =0A= That last sentence gave me heartburn. Just because nobody has made a=0A= disclosure does not mean something is "freely available for use with no=0A= claimed IPR." How about this:=0A= =0A= =0A= NEW=0A= IPR Disclosure: A pointer to any IPR disclosure document(s) related=0A= to this extension, or "None" if there are no such disclosures. This=0A= can be an IPR disclosure filed with the IETF in accordance with RFC=0A= 3979 [RFC3979] as updated by RFC 4879 [RFC4879] if the extension is=0A= part of an IETF Contribution, or can be other IPR disclosures=0A= documents identifying the claimed intellectual property rights and=0A= terms of use for extensions that are not part of an IETF Contribution.= =0A= =0A= OLD=0A= Status: Either "Active", "ACTIVE", "Inactive", or "INACTIVE".=0A= NEW=0A= Status: Either "ACTIVE" or "INACTIVE".=0A= =0A= OLD=0A= Notes: Either "None", "NONE", or other text=0A= NEW=0A= Notes: Either "NONE" or other text=0A= =0A= Change 3.2.2 to agree with the above (and eliminate the MUST and MAY in=0A= there too).=0A= =0A= 3.2.3:=0A= =0A= OLD=0A= Each registration form sent to IANA MUST contain a single record for=0A= incorporation into the registry. The form will be sent via email to=0A= by the extension registrant. It MUST have a=0A= subject...=0A= NEW=0A= Send each registration form to IANA with a single record for=0A= incorporation into the registry. The form will be sent via email to=0A= by the extension registrant, and will have a=0A= subject...=0A= =0A= 3.2.4:=0A= =0A= OLD=0A= All changes to existing registry entries MUST be documented with text= =0A= in the "Notes" field of the registration form. Under normal=0A= circumstances registry entries MAY only be updated by the registrant.= =0A= If the registrant becomes unavailable or otherwise unresponsive, the=0A= designated expert MAY submit a registration form to IANA to update=0A= the registrant information. Entries MAY change state from "Active"...= =0A= NEW=0A= When submitting changes to existing registry entries, include text in= =0A= the "Notes" field of the registration form describing the change.=0A= Under normal circumstances, registry entries are only be updated by=0A= the registrant. If the registrant becomes unavailable or otherwise=0A= unresponsive, the designated expert can submit a registration form to= =0A= IANA to update the registrant information. Entries can change state=0A= from "Active"...=0A= =0A= That's it. Let me know what you think. I'll mark the document in the=0A= tracker as "Revised I-D Needed".=0A= =0A= pr=0A= =0A= --=0A= Pete Resnick=0A= Qualcomm Technologies, Inc. - +1 (858)651-4478=0A= =0A= _______________________________________________=0A= EppExt mailing list=0A= EppExt@ietf.org=0A= https://www.ietf.org/mailman/listinfo/eppext=0A= From nobody Tue Sep 2 07:19:55 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29441A03BA for ; Tue, 2 Sep 2014 07:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0Y57PFrE_u5 for ; Tue, 2 Sep 2014 07:19:50 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725981A02EB for ; Tue, 2 Sep 2014 07:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1409667590; x=1441203590; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4zf36+SKgSAl53HF234z5NY6TJqvt3Acc9Pr2vtLtnk=; b=AqNqZ0AwphdEKtN84HhIS1H1Ogw4k2Aez8Z2b51t6PCku3zex6LYilFf eH4/LS+og9zzBLXeNRNLXD0R9fTcbjjAhmKUhrQsHHsd0EF6zG4OY6BJM kZudGni52tV+Bb+nOzTjoQtFMPmLyLA0Tw5X7UbPvEcEtW1aqWrMyMpoB M=; X-IronPort-AV: E=McAfee;i="5600,1067,7548"; a="73925940" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 02 Sep 2014 07:19:49 -0700 X-IronPort-AV: E=Sophos;i="5.04,449,1406617200"; d="scan'208";a="703246711" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Sep 2014 07:19:50 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 2 Sep 2014 07:19:48 -0700 Message-ID: <5405D203.4020100@qti.qualcomm.com> Date: Tue, 2 Sep 2014 09:19:47 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Gould, James" References: <54053671.9030409@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/AlU936pugaVJYcoeNEsZiGTUv4U Cc: "eppext@ietf.org" Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:19:52 -0000 On 9/2/14 7:45 AM, Gould, James wrote: > I have a few questions related to your suggestion in adding a new "Document Status" element. > > 1. What should the value be for a document that is intended to be Standards Track? I'm assuming that we would want to register drafts that are intended for Standards Track as they go through the process. > This is probably pretty similar to the procedure IANA uses now for other registries. They already have the concept of allocating codepoints while the document is going through the approval process and filling in the data once everything is finalized. I presume they'd put in a "To be standards track" or "TBD" or something like during the approval process. > 2. Will this get confused with the possible values defined in RFC 2026 or should we use the values as defined in RFC 2026? > I was only thinking in terms of "Standards Track" and "Informational", but I suppose "Experimental" and "Historic" might also be useful. ("BCP" wouldn't be useful.) > 3. Couldn't the official document status be determined by following the Specification Location in the case of an IETF document? For those documents that are not IETF documents, then following the Specification Location would not provide a document status. > Yes, you could discover the status just by looking up the document. I guess I figured it would be useful for the registry to make it obvious. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Sep 2 08:07:23 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EEF1A87A2 for ; Tue, 2 Sep 2014 08:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzEdCAAiWPSJ for ; Tue, 2 Sep 2014 08:07:12 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C98C1A87A3 for ; Tue, 2 Sep 2014 08:07:10 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKVAXdHf12BB1GehthBGa9R8bBwDgsaO74@postini.com; Tue, 02 Sep 2014 08:07:11 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s82F79Ln008757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 11:07:09 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 2 Sep 2014 11:07:08 -0400 From: "Gould, James" To: Pete Resnick Thread-Topic: [eppext] AD Review of draft-ietf-eppext-reg-07 Thread-Index: AQHPxlxNKaP1j2RJk0yawK6cpjlKFZvtxWqKgABi0YD//8QWpg== Date: Tue, 2 Sep 2014 15:07:08 +0000 Message-ID: References: <54053671.9030409@qti.qualcomm.com> , <5405D203.4020100@qti.qualcomm.com> In-Reply-To: <5405D203.4020100@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/prh_IovvqGT2zJqCUDIGOSHqBE4 Cc: "eppext@ietf.org" Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 15:07:15 -0000 Pete,=0A= =0A= Yes, having an explicit document status would be useful. Knowing the statu= s would be helpful to know whether or not a document may be of interest to = implement, be a candidate for merging, or just be a historical record of it= s existence. It may be useful to cover a few use cases to ensure that ever= ything is covered:=0A= =0A= 1. Registering an existing RFC - I believe this is already covered and coul= d reflect the document status as defined in RFC 2026.=0A= 2. Registering an I-D intended for Standards Track - Register with a docume= nt status like "To be standards track" or "Intended for Standards Track" = =0A= 3. Registering an I-D that falls into a Non-Standards Track ("Informational= ", "Experimental", "Historic" ), as defined in RFC 2026, - Register with RF= C 2026 Non-Standards Track value=0A= 4. Registering a non-I-D document - Register with an RFC 2026 Non-Standards= Track value=0A= 5. Merging documents to a Standards Track document ("Intended for Standards= Track") - Insert new document with "Intended for Standards Track" and mark= the pre-merge documents as "Historic". =0A= 6. Document moves up Standards Track maturity - Update the document with th= e appropriate status and new Specification Location. This could be handled= via a new insert and updating the previous version accordingly. If the in= sert and update previous version option is taken, is there any need to prov= ide a reference back (e.g. Obsoletes)? Doing so would pretty much replicat= e what is already supported in the IETF document, which I believe is unnece= ssary duplication. =0A= =0A= These are some of the use cases from the top of my head. Are there others = that are missing?=0A= =0A= Thanks,=0A= =0A= Jim=0A= =0A= ________________________________________=0A= From: Pete Resnick [presnick@qti.qualcomm.com]=0A= Sent: Tuesday, September 02, 2014 10:19 AM=0A= To: Gould, James=0A= Cc: eppext@ietf.org=0A= Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07=0A= =0A= On 9/2/14 7:45 AM, Gould, James wrote:=0A= =0A= > I have a few questions related to your suggestion in adding a new "Docume= nt Status" element.=0A= >=0A= > 1. What should the value be for a document that is intended to be Standar= ds Track? I'm assuming that we would want to register drafts that are inte= nded for Standards Track as they go through the process.=0A= >=0A= =0A= This is probably pretty similar to the procedure IANA uses now for other=0A= registries. They already have the concept of allocating codepoints while=0A= the document is going through the approval process and filling in the=0A= data once everything is finalized. I presume they'd put in a "To be=0A= standards track" or "TBD" or something like during the approval process.=0A= =0A= > 2. Will this get confused with the possible values defined in RFC 2026 or= should we use the values as defined in RFC 2026?=0A= >=0A= =0A= I was only thinking in terms of "Standards Track" and "Informational",=0A= but I suppose "Experimental" and "Historic" might also be useful. ("BCP"=0A= wouldn't be useful.)=0A= =0A= > 3. Couldn't the official document status be determined by following the S= pecification Location in the case of an IETF document? For those documents= that are not IETF documents, then following the Specification Location wou= ld not provide a document status.=0A= >=0A= =0A= Yes, you could discover the status just by looking up the document. I=0A= guess I figured it would be useful for the registry to make it obvious.=0A= =0A= pr=0A= =0A= --=0A= Pete Resnick=0A= Qualcomm Technologies, Inc. - +1 (858)651-4478=0A= =0A= From nobody Tue Sep 2 11:43:51 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A4D1A063F for ; Tue, 2 Sep 2014 11:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce2Ay16LyjMr for ; Tue, 2 Sep 2014 11:43:47 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BDC11A0655 for ; Tue, 2 Sep 2014 11:43:46 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKVAYP4TcCWj3RSVJhHfxZj5EWpF/MrjQD@postini.com; Tue, 02 Sep 2014 11:43:46 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s82Ihixo024527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 14:43:45 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 2 Sep 2014 14:43:44 -0400 From: "Hollenbeck, Scott" To: Pete Resnick , "eppext@ietf.org" Thread-Topic: [eppext] AD Review of draft-ietf-eppext-reg-07 Thread-Index: AQHPxlxNJlh6aloOvUO+qP+i6zFiC5vuLcuQ Date: Tue, 2 Sep 2014 18:43:44 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494A660B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <54053671.9030409@qti.qualcomm.com> In-Reply-To: <54053671.9030409@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/Ig57-AsDSJQSRLdJN_cnyraD9Ps Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 18:43:49 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Pete Resnick > Sent: Monday, September 01, 2014 11:16 PM > To: eppext@ietf.org > Subject: [eppext] AD Review of draft-ietf-eppext-reg-07 >=20 > At long last, my AD Review of draft-ietf-eppext-reg-07. My apologies > for > the delay. >=20 > First, please don't worry about the length of this message. As long as > it is, there's nothing earth shattering in here. The number of changes > I > suggest are actually pretty small, but I wanted to give you a good > explanation of why I suggested them. >=20 > So, first an overall comment: >=20 > My understanding is that right now, caveat the initial registrations in > section 4 (more on them in a moment), the things that go into this > registry are being put there for "informational" purposes. That is, > it's > a place to document the way things are being done now, but not > indicating any form of endorsement for one way over the other. However, > my understanding of the purpose of this registry is so that the EPP > community can, over the long term, harmonize extensions. That is, we > want folks to register these things so that folks who are developing > extensions might look and see, "Oh, that one does what I need; I should > just use that one." Furthermore, over time, folks might decide, "Hey, > these three extensions do the same thing; let's pick one way of doing > it." If the community agrees, they can "standardize" that way of doing > things. That will make life easier on registrars (and everyone for that > matter) so that folks won't have to implement the same thing multiple > different ways. I would expect that the way that would happen would be > to create a IETF Standards Track RFC for those extensions that everyone > agrees are "*the* way to do this thing". >=20 > So it seems to me that, while most of the things expected to be > registered here are strictly "informational" documents (mostly outside > of the IETF), we might want to have an extra column in the registry to > indicate the standards status of the registry entry so that people can > see if there is a particular item that is standard. It also seems to me > that if a registration is an IETF Standards Track document, that should > indicate that it has already gotten sufficient review and therefore the > Designated Experts don't need to. >=20 > So my suggestions are to address this are: >=20 > 1. In section 3.1.1, add: "If the specification for the registration is > an IETF Standards Track document, no review is required by the > Designated Expert." >=20 > 2. In section 3.2.1: >=20 > OLD > Registrant Name and Email Address: The case-insensitive name and > email address of the person that is responsible for managing the > registry entry. > NEW > 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 " >=20 > (I don't think you need to specify "case-insensitive" above, especially > because it doesn't make sense in some languages.) >=20 > Also add: >=20 > Document Status: The document status ("Informational", "Standards > Track", etc.) of the specification document. For documents that are > not RFCs, this will always be "Informational". >=20 > So, getting back to the initial 4 registrations (RFCs 3915, 4114, 5076, > and 5910): Each of those is currently on the Standards Track. I would > presume that they would each go into the registry as "Document Status: > Standards Track", presuming that they've already gotten community > consensus that they are "*the* way to do this thing". (Otherwise, they > probably shouldn't have been on the Standards Track in the first place, > in which case we should probably have a discussion about what to do.) >=20 > Does all that make sense? It does. > Other more minor comments: >=20 > (Overall editorial note: Generally, I find the use of the 2119 language > in this document unnecessary. We're supposed to use those terms where > interoperability is needed, and here they just seem a bit overdone. > Also, I don't think that you need to say things like "'Any' or 'ANY'", > since if you're going to allow them to be case-insensitive, "AnY" and > "aNY" and all the other silly ones could also be used. And that said, I > don't think you need to specify case-insensitive; it's a form that will > be handled by humans. Just give one example, either in title case or > upper case, and be done with it.) >=20 > 3.1, first paragraph, I suggest: >=20 > NEW > This registry uses the "Specification Required" policy described in > RFC 5226 [RFC5226]. An English language version of the extension > specification will appear in the registry, though non-English > versions of the specification can also be provided. Note that > Section 2.1 of RFC 3735 [RFC3735] provides specific guidelines for > documenting EPP extensions. >=20 > 3.2.1: >=20 > OLD > Specification Location: A URL [RFC3986] that describes the location > of the specification. >=20 > I suspect that won't satisfy IANA, as they generally want a stable > reference, though they will take a URL if need be. 5226 says: >=20 > Specification Required - Values and their meanings must be > documented in a permanent and readily available public > specification [...] The intention behind > "permanent and readily available" is that a document can > reasonably be expected to be findable and retrievable long > after IANA assignment of the requested value. >=20 > How about instead simply saying: >=20 > NEW > Reference: A reference to the specification of this extension. This > could be an RFC number or some other pointer to the document > defining > the extension. >=20 > OLD > TLDs: A case-insensitive text string description of the top-level > domain (or domains) for which the extension has been specified. > "Any" or "ANY" MUST be used if the extension is not associated with > a > specific top-level domain. Multiple TLDs SHOULD be specified as a > list of domain names separated by commas, e.g. ".com, .net". > Internationalized Domain Name (IDN) TLDs should be specified in > A-label [RFC5890] format. >=20 > "A case-insensitive text string description of the top-level domain" > seems weird. First, if we're using A-Labels, we already know they're > case-insensitive. Second, the string *is* the domain name, isn't it? > Finally, you should be clear to include the "." at the beginning. How > about instead: >=20 > NEW > TLDs: A text string containing the top-level domain name (or > domains > names), including the preceding ".", for which the extension has > been > specified (e.g., ".org"). If there are multiple TLDs, they are > given > as a list of domain names separated by commas, (e.g. ".com, .net"). > Internationalized Domain Name (IDN) TLDs should be specified in > A-label [RFC5890] format. If the extension is not associated with a > specific top-level domain, the case-insensitive text string "ANY" > can > be used to indicate that. >=20 > OLD > IPR Disclosure: Either "None", "NONE", or a URL that describes the > location of an IPR disclosure document. Depending on the type of > specification the IPR disclosure MAY be filed with the IETF in > accordance with RFC 3979 [RFC3979] as updated by RFC 4879 > [RFC4879]. > Non-IETF IPR disclosures MUST clearly identify the claimed > intellectual property rights and terms of use. "None" or "NONE" > indicates that the extension is freely available for use with no > claimed intellectual property rights. >=20 > That last sentence gave me heartburn. Just because nobody has made a > disclosure does not mean something is "freely available for use with no > claimed IPR." How about this: >=20 >=20 > NEW > IPR Disclosure: A pointer to any IPR disclosure document(s) related > to this extension, or "None" if there are no such disclosures. > This > can be an IPR disclosure filed with the IETF in accordance with RFC > 3979 [RFC3979] as updated by RFC 4879 [RFC4879] if the extension is > part of an IETF Contribution, or can be other IPR disclosures > documents identifying the claimed intellectual property rights and > terms of use for extensions that are not part of an IETF > Contribution. >=20 > OLD > Status: Either "Active", "ACTIVE", "Inactive", or "INACTIVE". > NEW > Status: Either "ACTIVE" or "INACTIVE". >=20 > OLD > Notes: Either "None", "NONE", or other text > NEW > Notes: Either "NONE" or other text >=20 > Change 3.2.2 to agree with the above (and eliminate the MUST and MAY in > there too). >=20 > 3.2.3: >=20 > OLD > Each registration form sent to IANA MUST contain a single record > for > incorporation into the registry. The form will be sent via email > to > by the extension registrant. It MUST have a > subject... > NEW > Send each registration form to IANA with a single record for > incorporation into the registry. The form will be sent via email > to > by the extension registrant, and will have a > subject... >=20 > 3.2.4: >=20 > OLD > All changes to existing registry entries MUST be documented with > text > in the "Notes" field of the registration form. Under normal > circumstances registry entries MAY only be updated by the > registrant. > If the registrant becomes unavailable or otherwise unresponsive, > the > designated expert MAY submit a registration form to IANA to update > the registrant information. Entries MAY change state from > "Active"... > NEW > When submitting changes to existing registry entries, include text > in > the "Notes" field of the registration form describing the change. > Under normal circumstances, registry entries are only be updated by > the registrant. If the registrant becomes unavailable or otherwise > unresponsive, the designated expert can submit a registration form > to > IANA to update the registrant information. Entries can change > state > from "Active"... >=20 > That's it. Let me know what you think. I'll mark the document in the > tracker as "Revised I-D Needed". I appreciate the suggestions and I'm comfortable with all of them. I'll get= a new version out next week barring any on-list disagreement. Scott From nobody Mon Sep 8 06:32:21 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55EC1A87D6; Mon, 8 Sep 2014 06:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCHSjTey9Lz5; Mon, 8 Sep 2014 06:32:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5511A87D5; Mon, 8 Sep 2014 06:32:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140908133218.14102.87137.idtracker@ietfa.amsl.com> Date: Mon, 08 Sep 2014 06:32:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/Hs8X1IJYzIZbBWNH0BnbqRDneTI Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-reg-08.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 13:32:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Provisioning Protocol Extensions Working Group of the IETF. Title : Extension Registry for the Extensible Provisioning Protocol Author : Scott Hollenbeck Filename : draft-ietf-eppext-reg-08.txt Pages : 11 Date : 2014-09-08 Abstract: The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP and it specifies a format for an IANA registry to record those extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-reg-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-reg-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 8 06:35:46 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE961A87DE for ; Mon, 8 Sep 2014 06:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh-4vqF3e0wh for ; Mon, 8 Sep 2014 06:35:43 -0700 (PDT) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEEE81A87D0 for ; Mon, 8 Sep 2014 06:35:42 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKVA2wrvPFoZzMD5KlDvwhOZwVcUdenP5V@postini.com; Mon, 08 Sep 2014 06:35:43 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s88DZfEo005523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 09:35:41 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 8 Sep 2014 09:35:41 -0400 From: "Hollenbeck, Scott" To: Pete Resnick , "eppext@ietf.org" Thread-Topic: [eppext] AD Review of draft-ietf-eppext-reg-07 Thread-Index: AQHPxlxNJlh6aloOvUO+qP+i6zFiC5v3RilA Date: Mon, 8 Sep 2014 13:35:40 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494ACB27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <54053671.9030409@qti.qualcomm.com> In-Reply-To: <54053671.9030409@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/cyfjnHhNfiCwL97iwu38zQX3w44 Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 13:35:45 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Pete Resnick > Sent: Monday, September 01, 2014 11:16 PM > To: eppext@ietf.org > Subject: [eppext] AD Review of draft-ietf-eppext-reg-07 >=20 > At long last, my AD Review of draft-ietf-eppext-reg-07. My apologies > for > the delay. I just posted draft-ietf-eppext-reg-08. It incorporates all of Pete's sugge= stions, and one that he didn't explicitly suggest. When I removed the RFC 2= 119 text I was left with a first section that included only three acronyms.= I removed that section and expanded the acronyms where they were first use= d. Scott From nobody Mon Sep 8 10:58:28 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF8B1A00FB for ; Mon, 8 Sep 2014 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFYO08ifjHHs for ; Mon, 8 Sep 2014 10:58:25 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9CB1A00FF for ; Mon, 8 Sep 2014 10:58:13 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKVA3uNWcqih16qHgpuKEATpYs+FSrH/ST@postini.com; Mon, 08 Sep 2014 10:58:14 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s88HwClE013324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Sep 2014 13:58:12 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 8 Sep 2014 13:58:11 -0400 From: "Gould, James" To: "eppext@ietf.org" Thread-Topic: draft-ietf-eppext-launchphase and draft-ietf-eppext-tmch-smd status Thread-Index: AQHPy450Cfh5jH8F00OYUaoj2uDTgw== Date: Mon, 8 Sep 2014 17:58:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_B7919A27FAA04516AB06A08C22E451DDverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/LGnFaoFIJZcqS1QZBdh4Z_BBIKI Subject: [eppext] draft-ietf-eppext-launchphase and draft-ietf-eppext-tmch-smd status X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 17:58:27 -0000 --_004_B7919A27FAA04516AB06A08C22E451DDverisigncom_ Content-Type: multipart/alternative; boundary="_000_B7919A27FAA04516AB06A08C22E451DDverisigncom_" --_000_B7919A27FAA04516AB06A08C22E451DDverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, The authors of both draft-ietf-eppext-launchphase and draft-ietf-eppext-tmc= h-smd believe that the drafts are ready for WG last call, but there is one = additional development that I wanted to bring up to the WG. There is work = being done at ICANN in the protection of IGO, INGO, Red Cross, and IOC doma= in names that may require the need for a claims like service similar to wha= t is currently supported by draft-ietf-eppext-launchphase for trademarks. = It is still early yet to discuss the details of this specific item, but it = raises the question of whether draft-ietf-eppext-launchphase should be capa= ble of supporting multiple distinct claims lists. Currently draft-ietf-epp= ext-launchphase is not tied to a single Trademark Clearinghouse with the us= e of the optional =93validatorID=94 attribute in the , , and elements, along with the extensibility of= mark and signedMark defined in draft-ietf-eppext-tmch-smd. If there is more than one claims list and claims notice service (TMCH, cust= om TMCH, and IGO/INGO/RC/IOC), then there is the possibility that a domain = name may be in more than one list. If that is the case, should draft-ietf-= eppext-launchphase support zero or more elements in the C= laims Check Response and should draft-ietf-eppext-launchphase support zero = or more elements in the Domain Create Command in place of= the existing zero to one cardinality? The =93validatorID=94 attribute wou= ld need to be mapped to the appropriate claims service by the client and se= rver. Thoughts and comments are appreciated. Thanks, =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_B7919A27FAA04516AB06A08C22E451DDverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <28F17D3A75CD3649B5F812C5482C3E3B@verisign.com> Content-Transfer-Encoding: quoted-printable All,

The authors of both draft-ietf-eppext-launchphase and draft-= ietf-eppext-tmch-smd believe that the drafts are ready for WG last call, bu= t there is one additional development that I wanted to bring up to the WG. =  There is work being done at ICANN in the protection of IGO, INGO, Red Cross, and IOC domain names that may require = the need for a claims like service similar to what is currently supported b= y draft-ietf-eppext-launchphase for trademarks.  It is still early yet= to discuss the details of this specific item, but it raises the question of whether draft-ietf-eppext-launchphase = should be capable of supporting multiple distinct claims lists.  Curre= ntly draft-ietf-eppext-launchphase is not tied to a single Trademark Cleari= nghouse with the use of the optional =93validatorID=94 attribute in the <launch:code>, <launch:claimKe= y>, and <launch:noticeID> elements, along with the extensibility o= f mark and signedMark defined in draft-ietf-eppext-tmch-smd.  

If there is more than one claims list and claims notice service (TMCH,= custom TMCH, and IGO/INGO/RC/IOC), then there is the possibility that a do= main name may be in more than one list.  If that is the case, should d= raft-ietf-eppext-launchphase support zero or more <launch:claimKey> elements in the Claims Check Response= and should draft-ietf-eppext-launchphase support zero or more <launch:n= oticeID> elements in the Domain Create Command in place of the existing = zero to one cardinality?  The =93validatorID=94 attribute would need to be mapped to the appropriate claims service by the= client and server.  

Thoughts and comments are appreciated.

Thanks, 

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Principal Software Engineer
jgould@Verisign.com

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

VerisignI= nc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_B7919A27FAA04516AB06A08C22E451DDverisigncom_-- --_004_B7919A27FAA04516AB06A08C22E451DDverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Mon, 08 Sep 2014 17:58:11 GMT"; modification-date="Mon, 08 Sep 2014 17:58:11 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_B7919A27FAA04516AB06A08C22E451DDverisigncom_-- From nobody Mon Sep 8 23:46:08 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DD61A0B02 for ; Mon, 8 Sep 2014 23:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1K5SHmlAcx3 for ; Mon, 8 Sep 2014 23:46:03 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id E13011A086C for ; Mon, 8 Sep 2014 23:46:02 -0700 (PDT) Received: from [218.241.103.178] (unknown [218.241.103.178]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QJAjog5UKBACAA--.5101S2; Tue, 09 Sep 2014 14:45:56 +0800 (CST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494ACB27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 9 Sep 2014 14:45:55 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54053671.9030409@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F494ACB27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0A5QJAjog5UKBACAA--.5101S2 X-Coremail-Antispam: 1UD129KBjvJXoW7KF43ZF18Zw4UGrW5uryUZFb_yoW8CF4kpF 47X3WYk3Z8Jw18G34xtw109340vryFvr48WrnYvr1kAay5Ja4kKr4ak3Z5Za4xGw4rK3WD tw1Uur1UZw1DAaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUk2b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r47MxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUxBOJUUUUU X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/W9MdXXKnWAVhmKMwAUBOgl4tIpQ Cc: Pete Resnick , "eppext@ietf.org" Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 06:46:05 -0000 Hi Scott, According to the section 2.2 (Identifying Extensions) of RFC 3735, an = EPP extension is uniquely identified by a Uniform Resource Identifier = (URI). It seems to me the issue of identifying extensions be covered by = the section 2.2.1 of draft-ietf-eppext-reg-08. It says, Reference: A reference to the specification of this extension. This could be an RFC number or some other pointer to the document defining the extension. I=A1=AFm confused by the above definition. It seems that the identifying = extensions method of draft-ietf-eppext-reg-08 doesn=A1=AFt follow the = RFC 3735. Either an RFC number or some other non-URI pointers may be = used to identify the extensions. BTW, I noticed that even the example form with RFC specification in = draft-ietf-eppext-reg-08 doesn=A1=AFt only use an RFC number as the = reference. So, IMHO, the definition of Reference in draft-ietf-eppext-reg-08 needs = to be modified in order to avoid such confusion. Cheers, Ning =D4=DA 2014=C4=EA9=D4=C28=C8=D5=A3=AC=CF=C2=CE=E79:35=A3=ACHollenbeck, = Scott =D0=B4=B5=C0=A3=BA >> -----Original Message----- >> From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Pete = Resnick >> Sent: Monday, September 01, 2014 11:16 PM >> To: eppext@ietf.org >> Subject: [eppext] AD Review of draft-ietf-eppext-reg-07 >>=20 >> At long last, my AD Review of draft-ietf-eppext-reg-07. My apologies >> for >> the delay. >=20 > I just posted draft-ietf-eppext-reg-08. It incorporates all of Pete's = suggestions, and one that he didn't explicitly suggest. When I removed = the RFC 2119 text I was left with a first section that included only = three acronyms. I removed that section and expanded the acronyms where = they were first used. >=20 > Scott >=20 > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext From nobody Tue Sep 9 02:34:28 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B22E1A89AD for ; Tue, 9 Sep 2014 02:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHhY6aWobMuh for ; Tue, 9 Sep 2014 02:34:24 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4BADE1A0A92 for ; Tue, 9 Sep 2014 02:34:24 -0700 (PDT) Received: from [218.241.103.178] (unknown [218.241.103.178]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0D5AJGdyQ5UbSICAA--.4701S2; Tue, 09 Sep 2014 17:34:21 +0800 (CST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: Date: Tue, 9 Sep 2014 17:34:20 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <191CC8E6-F98F-4CC0-94BE-1C2C3F5C5F3D@cnnic.cn> References: <54053671.9030409@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F494ACB27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0D5AJGdyQ5UbSICAA--.4701S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAF47JFW7Cr4rJFy5Kr1kAFb_yoW5Xr18pF 47X3Wakwn8Jw18Gw4xtw18K340vryFqr48GrnYyr1kJay5Ja4ktF1akF15Za4xGw4rKa1D tw1UWr1UZw1DA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkIb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Gr0_Cr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW8uwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IUYjXd5UUUUU== X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/qRK0IT79fvahsKd1cdLHqH_tIsU Cc: Pete Resnick , "eppext@ietf.org" Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 09:34:27 -0000 I reconsidered the issue I just raised. I think maybe I misunderstood = the meaning of Reference in the section 2.2.1 of = draft-ietf-eppext-reg-08. The Reference doesn=A1=AFt mean to be used as = identifying extensions, right? If so, I wonder if the URI used as identifying an extension needs to be = added as required information in section 2.2.1. IMO, URIs used to = identify the extensions with non-RFC specifications especially need to = be coordinated by IANA to avoid conflicts. Cheers, Ning =D4=DA 2014=C4=EA9=D4=C29=C8=D5=A3=AC=CF=C2=CE=E72:45=A3=ACNing Kong = =D0=B4=B5=C0=A3=BA >=20 > Hi Scott, >=20 > According to the section 2.2 (Identifying Extensions) of RFC 3735, an = EPP extension is uniquely identified by a Uniform Resource Identifier = (URI). It seems to me the issue of identifying extensions be covered by = the section 2.2.1 of draft-ietf-eppext-reg-08. It says, >=20 > Reference: A reference to the specification of this extension. This > could be an RFC number or some other pointer to the document = defining > the extension. >=20 > I=A1=AFm confused by the above definition. It seems that the = identifying extensions method of draft-ietf-eppext-reg-08 doesn=A1=AFt = follow the RFC 3735. Either an RFC number or some other non-URI pointers = may be used to identify the extensions. >=20 > BTW, I noticed that even the example form with RFC specification in = draft-ietf-eppext-reg-08 doesn=A1=AFt only use an RFC number as the = reference. >=20 > So, IMHO, the definition of Reference in draft-ietf-eppext-reg-08 = needs to be modified in order to avoid such confusion. >=20 > Cheers, > Ning >=20 >=20 > =D4=DA 2014=C4=EA9=D4=C28=C8=D5=A3=AC=CF=C2=CE=E79:35=A3=ACHollenbeck, = Scott =D0=B4=B5=C0=A3=BA >=20 >>> -----Original Message----- >>> From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Pete = Resnick >>> Sent: Monday, September 01, 2014 11:16 PM >>> To: eppext@ietf.org >>> Subject: [eppext] AD Review of draft-ietf-eppext-reg-07 >>>=20 >>> At long last, my AD Review of draft-ietf-eppext-reg-07. My apologies >>> for >>> the delay. >>=20 >> I just posted draft-ietf-eppext-reg-08. It incorporates all of Pete's = suggestions, and one that he didn't explicitly suggest. When I removed = the RFC 2119 text I was left with a first section that included only = three acronyms. I removed that section and expanded the acronyms where = they were first used. >>=20 >> Scott >>=20 >> _______________________________________________ >> EppExt mailing list >> EppExt@ietf.org >> https://www.ietf.org/mailman/listinfo/eppext >=20 >=20 > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext From nobody Wed Sep 10 09:15:15 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3DE1A877C for ; Wed, 10 Sep 2014 09:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6ntAFLx1_n5 for ; Wed, 10 Sep 2014 09:15:08 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD801A8757 for ; Wed, 10 Sep 2014 09:15:05 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKVBB5CaPU5xpqmbKj1uEu8u7cGKOViCA7@postini.com; Wed, 10 Sep 2014 09:15:07 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s8AGF24j003315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 12:15:04 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 12:15:02 -0400 From: "Hollenbeck, Scott" To: Ning Kong Thread-Topic: [eppext] AD Review of draft-ietf-eppext-reg-07 Thread-Index: AQHPxlxNJlh6aloOvUO+qP+i6zFiC5v4ZsNsgAByCQCAAb5rkA== Date: Wed, 10 Sep 2014 16:15:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494AF61C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <54053671.9030409@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F494ACB27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <191CC8E6-F98F-4CC0-94BE-1C2C3F5C5F3D@cnnic.cn> In-Reply-To: <191CC8E6-F98F-4CC0-94BE-1C2C3F5C5F3D@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/nKbQ4m6BM6Y11ZeH4bsp-0C8u9g Cc: Pete Resnick , "eppext@ietf.org" Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 16:15:11 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Ning Kong > Sent: Tuesday, September 09, 2014 5:34 AM > To: Hollenbeck, Scott > Cc: Pete Resnick; eppext@ietf.org > Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 >=20 >=20 > I reconsidered the issue I just raised. I think maybe I misunderstood > the meaning of Reference in the section 2.2.1 of draft-ietf-eppext-reg- > 08. The Reference doesn't mean to be used as identifying extensions, > right? Correct. It's intended to identify the document containing the specificatio= n. > If so, I wonder if the URI used as identifying an extension needs to be > added as required information in section 2.2.1. IMO, URIs used to > identify the extensions with non-RFC specifications especially need to > be coordinated by IANA to avoid conflicts. Needs to be added? I don't think so since there's already a registry for th= em and assignments are already being managed by IANA. It is potentially use= ful information, but it can (or should) be found within the specification i= tself. Scott From nobody Wed Sep 10 21:04:26 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2221A0348 for ; Wed, 10 Sep 2014 21:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4_HsVWet2cH for ; Wed, 10 Sep 2014 21:04:22 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 20F021A03AD for ; Wed, 10 Sep 2014 21:04:21 -0700 (PDT) Received: from [218.241.103.7] (unknown [218.241.103.7]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0Dpj4RBHxFUifMCAA--.6232S2; Thu, 11 Sep 2014 12:04:19 +0800 (CST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494AF61C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 11 Sep 2014 12:04:15 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2C673F27-DDB3-42B5-9E8D-B20B4E39D63E@cnnic.cn> References: <54053671.9030409@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F494ACB27@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <191CC8E6-F98F-4CC0-94BE-1C2C3F5C5F3D@cnnic.cn> <831693C2CDA2E849A7D7A712B24E257F494AF61C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0Dpj4RBHxFUifMCAA--.6232S2 X-Coremail-Antispam: 1UD129KBjvJXoW7AF1Uury7AFy7KF4kJr1kXwb_yoW8XrWUpw 43Gw4kKFs8Aw18Aw1xA3WUA34I9rs2kF43KrZ3t348Aas8Ga4ftryY9F4Y93WDurs7GF1q vayftrs8Z3yDAaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUk2b7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW8XwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUxyv3UUUUU X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/YAlBej0fLEEgu6_Z7tLKR1Ey9bA Cc: Pete Resnick , "eppext@ietf.org" Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 04:04:25 -0000 > Needs to be added? I don't think so since there's already a registry = for them and assignments are already being managed by IANA. It is = potentially useful information, but it can (or should) be found within = the specification itself. Thanks for your clarification. It seems that several other items (e.g. = Name of extension, Document Status) can also be found in the = specification ;-) On the other hand, since the specification contains useful information, = the reference of it is very important. Just as Pete mentioned, IANA = wants a stable reference. To be honest, I don=A1=AFt think the = definition of the reference in this version ensure this requirement. = I=A1=AFm afraid not every =A1=B0some other pointer=A1=B1 used as = reference can make sure the document can be findable and retrievable = long after IANA assignment. So I think the definition of the Reference = needs to be enhanced to ensure this requirement. Anyway, I=A1=AFm OK if the URI used as identifying extension is not be = added as required information. But, IMO if the URIs used as identifying = extensions can be directly provided by the IANA registry for EPP = extensions in future, rather than included within each reference, it = would be more convenient for the queriers, especially for the designers = of new EPP extensions, to quickly check whether their intended URIs were = allocated without needing to read every specifications of the IANA EPP = extension registry or jump to another IANA registry for XML to check. Cheers, Ning= From nobody Fri Sep 12 05:01:46 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8461A0716 for ; Fri, 12 Sep 2014 05:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkfDLg5_UDtO for ; Fri, 12 Sep 2014 05:01:40 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B0B1A0712 for ; Fri, 12 Sep 2014 05:01:39 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKVBLgodQ30SleuPUcomHZ9zDQ7ZaGk473@postini.com; Fri, 12 Sep 2014 05:01:39 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s8CC1a7u023756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 12 Sep 2014 08:01:37 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 12 Sep 2014 08:01:35 -0400 From: "Gould, James" To: "eppext@ietf.org" Thread-Topic: [eppext] draft-ietf-eppext-launchphase and draft-ietf-eppext-tmch-smd status Thread-Index: AQHPzoFMoP9XV/JQF0KNS50cIDxpVw== Date: Fri, 12 Sep 2014 12:01:34 +0000 Message-ID: <2956E729-CBBC-470F-963C-9EC33A9952CD@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_2956E729CBBC470F963C9EC33A9952CDverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/HoqFHZ7zET2eRSXAxNEdF4Kz2TI Subject: Re: [eppext] draft-ietf-eppext-launchphase and draft-ietf-eppext-tmch-smd status X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 12:01:43 -0000 --_004_2956E729CBBC470F963C9EC33A9952CDverisigncom_ Content-Type: multipart/alternative; boundary="_000_2956E729CBBC470F963C9EC33A9952CDverisigncom_" --_000_2956E729CBBC470F963C9EC33A9952CDverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, I received 2 positive responses privately for making the change to draft-ie= tf-eppext-launchphase that will make and a zero to many instead of a zero to one relationship under an= d , respectively. This will support more than one parallel = claims services if needed using the =93validatorID=94 to identify the speci= fic claims service. Please post a reply to the list or to me privately if = there is an issue with making this change. I will go ahead and start makin= g the draft upgrade with Gavin and Wil. Thanks, =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Sep 8, 2014, at 1:58 PM, Gould, James > wrote: All, The authors of both draft-ietf-eppext-launchphase and draft-ietf-eppext-tmc= h-smd believe that the drafts are ready for WG last call, but there is one = additional development that I wanted to bring up to the WG. There is work = being done at ICANN in the protection of IGO, INGO, Red Cross, and IOC doma= in names that may require the need for a claims like service similar to wha= t is currently supported by draft-ietf-eppext-launchphase for trademarks. = It is still early yet to discuss the details of this specific item, but it = raises the question of whether draft-ietf-eppext-launchphase should be capa= ble of supporting multiple distinct claims lists. Currently draft-ietf-epp= ext-launchphase is not tied to a single Trademark Clearinghouse with the us= e of the optional =93validatorID=94 attribute in the , , and elements, along with the extensibility of= mark and signedMark defined in draft-ietf-eppext-tmch-smd. If there is more than one claims list and claims notice service (TMCH, cust= om TMCH, and IGO/INGO/RC/IOC), then there is the possibility that a domain = name may be in more than one list. If that is the case, should draft-ietf-= eppext-launchphase support zero or more elements in the C= laims Check Response and should draft-ietf-eppext-launchphase support zero = or more elements in the Domain Create Command in place of= the existing zero to one cardinality? The =93validatorID=94 attribute wou= ld need to be mapped to the appropriate claims service by the client and se= rver. Thoughts and comments are appreciated. Thanks, =97 JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_2956E729CBBC470F963C9EC33A9952CDverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1B254248FF45F047B49155D9D8C0457C@verisign.com> Content-Transfer-Encoding: quoted-printable All,

I received 2 positive responses privately for making the change to dra= ft-ietf-eppext-launchphase that will make <launch:claimKey> and <l= aunch:noticeID> a zero to many instead of a zero to one relationship und= er <launch:cd> and <launch:notice>, respectively.  This will support more than one parallel claims services if needed u= sing the =93validatorID=94 to identify the specific claims service.  P= lease post a reply to the list or to me privately if there is an issue with= making this change.  I will go ahead and start making the draft upgrade with Gavin and Wil.  

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Principal Software Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Sep 8, 2014, at 1:58 PM, Gould, James <JGould@verisign.com> wrote:

All,

The authors of both draft-ietf-eppext-launchphase and draft-= ietf-eppext-tmch-smd believe that the drafts are ready for WG last call, bu= t there is one additional development that I wanted to bring up to the WG. =  There is work being done at ICANN in the protection of IGO, INGO, Red Cross, and IOC domain names that may require = the need for a claims like service similar to what is currently supported b= y draft-ietf-eppext-launchphase for trademarks.  It is still early yet= to discuss the details of this specific item, but it raises the question of whether draft-ietf-eppext-launchphase = should be capable of supporting multiple distinct claims lists.  Curre= ntly draft-ietf-eppext-launchphase is not tied to a single Trademark Cleari= nghouse with the use of the optional =93validatorID=94 attribute in the <launch:code>, <launch:claimKe= y>, and <launch:noticeID> elements, along with the extensibility o= f mark and signedMark defined in draft-ietf-eppext-tmch-smd.  

If there is more than one claims list and claims notice service (TMCH,= custom TMCH, and IGO/INGO/RC/IOC), then there is the possibility that a do= main name may be in more than one list.  If that is the case, should d= raft-ietf-eppext-launchphase support zero or more <launch:claimKey> elements in the Claims Check Response= and should draft-ietf-eppext-launchphase support zero or more <launch:n= oticeID> elements in the Domain Create Command in place of the existing = zero to one cardinality?  The =93validatorID=94 attribute would need to be mapped to the appropriate claims service by the= client and server.  

Thoughts and comments are appreciated.

Thanks, 

=97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>

James Gould
Principal Software Engineer
jgould@Verisign.com

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

Verisign= Inc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/eppext

--_000_2956E729CBBC470F963C9EC33A9952CDverisigncom_-- --_004_2956E729CBBC470F963C9EC33A9952CDverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 12 Sep 2014 12:01:34 GMT"; modification-date="Fri, 12 Sep 2014 12:01:34 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_2956E729CBBC470F963C9EC33A9952CDverisigncom_-- From nobody Fri Sep 12 07:56:57 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629C31A6F32 for ; Fri, 12 Sep 2014 07:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsFlC5HPR67r for ; Fri, 12 Sep 2014 07:56:52 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6D61A006A for ; Fri, 12 Sep 2014 07:56:51 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKVBMJsxsVWIt/gYd3A5SsnOhFcp+7cx0H@postini.com; Fri, 12 Sep 2014 07:56:51 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s8CEuo7W028981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 12 Sep 2014 10:56:50 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 12 Sep 2014 10:56:50 -0400 From: "Gould, James" To: "eppext@ietf.org" Thread-Topic: [eppext] Request for EPPEXT Meeting at IETF 91 Thread-Index: AQHPsXXqTKxMPX+D/Eyu1eNgZKnRgZv+E7GA Date: Fri, 12 Sep 2014 14:56:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_AD350122208A42659635C101A91B9399verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/2TGx32bRsQZjzlMb9AUvbDUoqy8 Subject: Re: [eppext] Request for EPPEXT Meeting at IETF 91 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 14:56:54 -0000 --_004_AD350122208A42659635C101A91B9399verisigncom_ Content-Type: multipart/alternative; boundary="_000_AD350122208A42659635C101A91B9399verisigncom_" --_000_AD350122208A42659635C101A91B9399verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I sent the following request over a month ago and now there is only 2 weeks= left to meet the cut-off date for a Working Group meeting. Could our chai= rs step up and arrange a meeting? Based on what is on the WG charter, we h= ave the following remaining work: 1. Progress draft-ietf-eppext-launchphase and draft-ietf-eppext-tmch-smd= - There is one planned change that has been discussed on the list and that= will be incorporated into an updated draft. The hope is that both drafts = will be complete and ready for WG last call, but if not we can use the meet= ing to discuss any open items that remain. 2. Discuss draft-ietf-eppext-keyrelay open items discussed on the list t= o progress a new version of the draft. As a reminder, the two options disc= ussed included structuring it as an object extension or as a command-respon= se extension. This is a good general topic on when to use a protocol exten= sion, object extension, or a command-response extension for a draft that is= in our charter. I described structuring draft-ietf-eppext-keyrelay as eit= her a command-response extension or an object extension in the http://www.i= etf.org/mail-archive/web/eppext/current/msg00073.html posting. 3. Discuss draft-ietf-eppext-idnmap open items discussed on the list. I= raised a list of open questions in the http://www.ietf.org/mail-archive/we= b/eppext/current/msg00115.html posting. I provided a proposal to address m= y concern in the http://www.ietf.org/mail-archive/web/eppext/current/msg000= 72.html posting. I believe that it will require discussing the IDN registr= ation flows supported by the various registries and how draft-ietf-eppext-i= dnmap can support them. We have our own custom IDN Language Tag EPP Extens= ion ( http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_idn-= lang_v00.html ) that I would like to eventually replace with draft-ietf-epp= ext-idnmap, but draft-ietf-eppext-idnmap does not currently support the int= erface needed. I believe we can come to an agreement after discussing the = options. I want this WG to be successful in completing its charter, but we must have= active participation on the list and we need to meet to make progress on c= losing out our remaining work. I will provide support in making this happe= n. Thanks, =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Aug 6, 2014, at 8:57 AM, Gould, James > wrote: All, We did not have an opportunity to meet at IETF 90. With draft-ietf-eppext-= reg progressing, there is additional business that needs to be discussed. = I request that we schedule a meeting at IETF 91 to move the other items for= ward, that include: 1. Progress draft-ietf-eppext-launchphase - Gavin, Wil, and I are in agr= eement that the draft is stable, has multiple independent implementations, = and is ready to move forward. 2. Progress draft-ietf-eppext-tmch-smd =96 There is a dependency from dr= aft-ietf-eppext-launchphase to draft-ietf-eppext-tmch-smd, and both are sta= ble and have multiple independent implementations. Gustavo can comment on = whether he knows of any open items remaining with draft-ietf-eppext-tmch-sm= d to address prior to moving it forward. 3. Discuss draft-ietf-eppext-keyrelay open items discussed on the list t= o progress a new version of the draft. Based on the latest posts on the li= st, the agreement was to register it "as is=94 and to progress a new versio= n of the draft. 4. Discuss draft-ietf-eppext-idnmap open items discussed on the list. I= n review, Francisco and I have discussed handling of the existing table mod= el and a proposal that I had for a language model. Is there other business that could be handled with an EPPEXT meeting at IET= F 91? Thanks, -- JG <3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[59].png> James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_AD350122208A42659635C101A91B9399verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <323A0F209C01E34BAB774E35E47D988F@verisign.com> Content-Transfer-Encoding: quoted-printable I sent the following request over a month ago and now there is only 2 weeks= left to meet the cut-off date for a Working Group meeting.  Could our= chairs step up and arrange a meeting?  Based on what is on the WG cha= rter, we have the following remaining work:

  1. Progress draft-ietf-eppext-launchphase and draft-ietf-eppext-tmch-smd -= There is one planned change that has been discussed on the list and that w= ill be incorporated into an updated draft.  The hope is that both draf= ts will be complete and ready for WG last call, but if not we can use the meeting to discuss any open items tha= t remain.  
  2. Discuss draft-ietf-eppext-keyrelay open items disc= ussed on the list to progress a new version of the draft.  As a remind= er, the two options discussed included structuring it as an object extensio= n or as a command-response extension.  This is a good general topic on when to use a protocol extension, object extension, or a command-= response extension for a draft that is in our charter.  I described st= ructuring draft-ietf-eppext-keyrelay as either a command-response extension= or an object extension in the http://www.ietf.org/mail-archive/web/eppext/current/msg00073.html po= sting.
  3. Discuss draft-ietf-eppext-idnmap open items discussed on the= list.  I raised a list of open questions in the http://www.ietf.org/mail-archive/web/eppext/current/msg00115.html po= sting.  I provided a proposal to address my concern in the http://www.ietf.org/mail-archive/web/eppext/current/msg00072.html po= sting.  I believe that it will require discussing the IDN registration= flows supported by the various registries and how draft-ietf-eppext-idnmap can support them.  We have our = own custom IDN Language Tag EPP Extension ( http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_idn-lang_v= 00.html ) that I would like to eventually replace with draft-ietf-= eppext-idnmap, but draft-ietf-eppext-idnmap does not currently support= the interface needed.  I believe we can come to an agreement after discussing the options.         =         

I want this WG to be successful in completing its charter, but we must= have active participation on the list and we need to meet to make progress= on closing out our remaining work.  I will provide support in making = this happen.

Thanks,  

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Principal Software Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Aug 6, 2014, at 8:57 AM, Gould, James <JGould@verisign.com> wrote:

All,

We did not have an opportunity to meet at IETF 90.  With dra= ft-ietf-eppext-reg progressing, there is additional business that needs to = be discussed.  I request that we schedule a meeting at IETF 91 to move= the other items forward, that include:
  1. Progress draft-ietf-eppext-launchphase - Gavin, Wil, and I are in = agreement that the draft is stable, has multiple independent implementation= s, and is ready to move forward.  
  2. Progress draft-ietf-ep= pext-tmch-smd =96 There is a dependency from draft-ietf-eppext-launchp= hase to draft-ietf-eppext-tmch-smd, and both are stable and have multi= ple independent implementations.  Gustavo can comment on whether he kn= ows of any open items remaining with draft-ietf-eppext-tmch-smd to address prior to moving it forward.
  3. Discuss draft-ietf-eppext-keyrelay open items discussed on the list to= progress a new version of the draft.  Based on the latest posts on th= e list, the agreement was to register it "as is=94 and to progress a n= ew version of the draft.  
  4. Discuss draft-ietf-eppext-idnm= ap open items discussed on the list.  In review, Francisco and I have = discussed handling of the existing table model and a proposal that I had fo= r a language model.  
Is there other business that could be handled with an EPPEXT meeting a= t IETF 91?

Thanks,

-- 
 
JG
 
<3CA91A0B-A6C1-43A5-AC92-8E= 23C9AD1B74[59].png>
 
James Gould
Principal Software Engineer
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/eppext

--_000_AD350122208A42659635C101A91B9399verisigncom_-- --_004_AD350122208A42659635C101A91B9399verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 12 Sep 2014 14:56:49 GMT"; modification-date="Fri, 12 Sep 2014 14:56:49 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_AD350122208A42659635C101A91B9399verisigncom_-- From nobody Fri Sep 12 08:02:01 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045BE1A01A9 for ; Fri, 12 Sep 2014 08:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG5hjiNeOyge for ; Fri, 12 Sep 2014 08:01:55 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909551A0BEB for ; Fri, 12 Sep 2014 08:01:50 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKVBMK3tfVn71kUZMoJqqLHZmepYeY5Ya1@postini.com; Fri, 12 Sep 2014 08:01:50 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s8CF1no4025801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 12 Sep 2014 11:01:49 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 12 Sep 2014 11:01:49 -0400 From: "Hollenbeck, Scott" To: "Gould, James" , "eppext@ietf.org" Thread-Topic: [eppext] Request for EPPEXT Meeting at IETF 91 Thread-Index: AQHPsXXqTKxMPX+D/Eyu1eNgZKnRgZv+E7GA//+9+ZA= Date: Fri, 12 Sep 2014 15:01:48 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494B1F78@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_831693C2CDA2E849A7D7A712B24E257F494B1F78BRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/cNmeHlAoC1vwlczFlJr4mvHhYt0 Subject: Re: [eppext] Request for EPPEXT Meeting at IETF 91 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 15:02:00 -0000 --_004_831693C2CDA2E849A7D7A712B24E257F494B1F78BRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F494B1F78BRN1WNEXMBX01vc_" --_000_831693C2CDA2E849A7D7A712B24E257F494B1F78BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We still have a number of expired WG drafts, too. Leadership, please? Scott From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James Sent: Friday, September 12, 2014 10:57 AM To: eppext@ietf.org Subject: Re: [eppext] Request for EPPEXT Meeting at IETF 91 I sent the following request over a month ago and now there is only 2 weeks= left to meet the cut-off date for a Working Group meeting. Could our chai= rs step up and arrange a meeting? Based on what is on the WG charter, we h= ave the following remaining work: 1. Progress draft-ietf-eppext-launchphase and draft-ietf-eppext-tmch-smd= - There is one planned change that has been discussed on the list and that= will be incorporated into an updated draft. The hope is that both drafts = will be complete and ready for WG last call, but if not we can use the meet= ing to discuss any open items that remain. 2. Discuss draft-ietf-eppext-keyrelay open items discussed on the list t= o progress a new version of the draft. As a reminder, the two options disc= ussed included structuring it as an object extension or as a command-respon= se extension. This is a good general topic on when to use a protocol exten= sion, object extension, or a command-response extension for a draft that is= in our charter. I described structuring draft-ietf-eppext-keyrelay as eit= her a command-response extension or an object extension in the http://www.i= etf.org/mail-archive/web/eppext/current/msg00073.html posting. 3. Discuss draft-ietf-eppext-idnmap open items discussed on the list. I= raised a list of open questions in the http://www.ietf.org/mail-archive/we= b/eppext/current/msg00115.html posting. I provided a proposal to address m= y concern in the http://www.ietf.org/mail-archive/web/eppext/current/msg000= 72.html posting. I believe that it will require discussing the IDN registr= ation flows supported by the various registries and how draft-ietf-eppext-i= dnmap can support them. We have our own custom IDN Language Tag EPP Extens= ion ( http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_idn-= lang_v00.html ) that I would like to eventually replace with draft-ietf-epp= ext-idnmap, but draft-ietf-eppext-idnmap does not currently support the int= erface needed. I believe we can come to an agreement after discussing the = options. I want this WG to be successful in completing its charter, but we must have= active participation on the list and we need to meet to make progress on c= losing out our remaining work. I will provide support in making this happe= n. Thanks, - JG [cid:image001.png@01CFCE78.F22B8710] James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Aug 6, 2014, at 8:57 AM, Gould, James > wrote: All, We did not have an opportunity to meet at IETF 90. With draft-ietf-eppext-= reg progressing, there is additional business that needs to be discussed. = I request that we schedule a meeting at IETF 91 to move the other items for= ward, that include: 1. Progress draft-ietf-eppext-launchphase - Gavin, Wil, and I are in agr= eement that the draft is stable, has multiple independent implementations, = and is ready to move forward. 2. Progress draft-ietf-eppext-tmch-smd - There is a dependency from draf= t-ietf-eppext-launchphase to draft-ietf-eppext-tmch-smd, and both are stabl= e and have multiple independent implementations. Gustavo can comment on wh= ether he knows of any open items remaining with draft-ietf-eppext-tmch-smd = to address prior to moving it forward. 3. Discuss draft-ietf-eppext-keyrelay open items discussed on the list t= o progress a new version of the draft. Based on the latest posts on the li= st, the agreement was to register it "as is" and to progress a new version = of the draft. 4. Discuss draft-ietf-eppext-idnmap open items discussed on the list. I= n review, Francisco and I have discussed handling of the existing table mod= el and a proposal that I had for a language model. Is there other business that could be handled with an EPPEXT meeting at IET= F 91? Thanks, -- JG <3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[59].png> James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_831693C2CDA2E849A7D7A712B24E257F494B1F78BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We still have a number of expired WG draft= s, too. Leadership, please?

 

Scott<= o:p>

 

From: EppExt [= mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James
Sent: Friday, September 12, 2014 10:57 AM
To: eppext@ietf.org
Subject: Re: [eppext] Request for EPPEXT Meeting at IETF 91

 

I sent the following request over a month ago and no= w there is only 2 weeks left to meet the cut-off date for a Working Group m= eeting.  Could our chairs step up and arrange a meeting?  Based o= n what is on the WG charter, we have the following remaining work:

 

  1. Progress draft-ietf-eppext-launchphase and draft-ietf-eppext-tmch-smd - The= re is one planned change that has been discussed on the list and that will = be incorporated into an updated draft.  The hope is that both drafts w= ill be complete and ready for WG last call, but if not we can use the meeting to discuss any open items that rem= ain.  
  2. Discuss draft-ietf-eppext-keyrelay open items discussed on the list to prog= ress a new version of the draft.  As a reminder, the two options discu= ssed included structuring it as an object extension or as a command-respons= e extension.  This is a good general topic on when to use a protocol extension, object extension, or a command-= response extension for a draft that is in our charter.  I described st= ructuring draft-ietf-eppext-keyrelay as either a command-response extension= or an object extension in the http://www.ietf.org/mail-archive/web/eppext/current/msg00073.html po= sting.
  3. Discuss draft-ietf-eppext-idnmap open items discussed on the list.  I = raised a list of open questions in the http://www.ietf.org/mail-archive/web/eppext/current/msg00115.html po= sting.  I provided a proposal to address my concern in the http://www.ietf.org/mail-archive/web/eppext/current/msg00072.html po= sting.  I believe that it will require discussing the IDN registration= flows supported by the various registries and how draft-ietf-eppext-idnmap can support them.  We have our = own custom IDN Language Tag EPP Extension ( http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_idn-lang_v= 00.html ) that I would like to eventually replace with draft-ietf-= eppext-idnmap, but draft-ietf-eppext-idnmap does not currently support= the interface needed.  I believe we can come to an agreement after discussing the options.         =         

 

I want this WG to be successful in completing its ch= arter, but we must have active participation on the list and we need to mee= t to make progress on closing out our remaining work.  I will provide = support in making this happen.

 

Thanks,  

 

R= 12;

 

JG




James Gould
Principal Software Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

On Aug 6, 2014, at 8:57 AM, Gould, James <JGould@verisign.com> wrote:



All,

 

We did not have an opportunity to meet = at IETF 90.  With draft-ietf-eppext-reg progressing, there is add= itional business that needs to be discussed.  I request that we schedu= le a meeting at IETF 91 to move the other items forward, that include:

  1. Progress draft-ietf-eppext-launchphase - Gavin, Wil, and = I are in agreement that the draft is stable, has multiple independent imple= mentations, and is ready to move forward.  
  2. Progress draft-ietf-eppext-tmch-smd – There is a de= pendency from draft-ietf-eppext-launchphase to draft-ietf-eppext-= tmch-smd, and both are stable and have multiple independent implementations= .  Gustavo can comment on whether he knows of any open items remaining = with draft-ietf-eppext-tmch-smd to address prior to moving it forward.=
  3. Discuss draft-ietf-eppext-keyrelay open items discussed on the= list to progress a new version of the draft.  Based on the latest pos= ts on the list, the agreement was to register it "as is” and to progress a new version of the draft.  
  4. Discuss draft-ietf-eppext-idnmap open items discussed on = the list.  In review, Francisco and I have discussed handling of the e= xisting table model and a proposal that I had for a language model.  

Is there other business that could be h= andled with an EPPEXT meeting at IETF 91?

 

Thanks,

 

-- 

 

JG

 

<3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[59].png><= /o:p>

 

James Gould

Principal Software Engineer

 

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

“This message (including any attachments) is intended only= for the use of the individual or entity to which it is addressed, and may = contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be con= stituted as attorney work product. If you are not the intended recipient, y= ou are hereby notified that any use, dissemination, distribution, or copyin= g of this communication is strictly prohibited. If you have received this message in error, notify sender imme= diately and delete this message immediately.”

_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.o= rg/mailman/listinfo/eppext

 

--_000_831693C2CDA2E849A7D7A712B24E257F494B1F78BRN1WNEXMBX01vc_-- --_004_831693C2CDA2E849A7D7A712B24E257F494B1F78BRN1WNEXMBX01vc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 12 Sep 2014 15:01:48 GMT"; modification-date="Fri, 12 Sep 2014 15:01:48 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_831693C2CDA2E849A7D7A712B24E257F494B1F78BRN1WNEXMBX01vc_-- From nobody Mon Sep 15 08:16:23 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5BC1A0387 for ; Mon, 15 Sep 2014 08:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.754 X-Spam-Level: X-Spam-Status: No, score=-6.754 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPpgCulPvSpk for ; Mon, 15 Sep 2014 08:16:17 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BC31A0391 for ; Mon, 15 Sep 2014 08:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1410794177; x=1442330177; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=RtwH3WG7iD2J+kvFmOHgvx7LUmw5dP4g8KaIbnAgmbM=; b=o3OBNzPvHKlQsEouBK+LQH6FsK8CfEDyBF0qmn3VtGtaEiaXpT/537uN yuEKoa32xz6P87U7H+xsfcwTBaoObnvUe+q2Y4Or50PpbYesCGHddweIs xU9YEpiD9lxuWAIWGQ94z5q3gqIZudHlaJ7nRHQWMu0zheM5xDKsqEoNS w=; X-IronPort-AV: E=McAfee;i="5600,1067,7561"; a="158773265" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 15 Sep 2014 08:16:16 -0700 X-IronPort-AV: E=Sophos;i="5.04,528,1406617200"; d="scan'208";a="711315036" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2014 08:16:16 -0700 Received: from NASANEXM01D.na.qualcomm.com (129.46.53.246) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 15 Sep 2014 08:16:15 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01D.na.qualcomm.com (129.46.53.246) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 15 Sep 2014 08:16:15 -0700 Message-ID: <541702BD.5080400@qti.qualcomm.com> Date: Mon, 15 Sep 2014 10:16:13 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <54053671.9030409@qti.qualcomm.com> In-Reply-To: <54053671.9030409@qti.qualcomm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01H.na.qualcomm.com (10.46.201.104) To NASANEXM01D.na.qualcomm.com (129.46.53.246) Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/Nb9boggj3TOM9ghW4GHvravJ8yY Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:16:20 -0000 One silly issue that I missed: I note that this document is marked as "Proposed Standard". My personal feeling is that creation of registries can simply be done as an "Informational" document, though I don't think it makes much difference. I can Last Call the document for Proposed Standard anyway and let the IESG make the call (one of the few things we are empowered to do independently), but I wanted to check: Does anybody care strongly one way or the other? If not, I'll note in the Last Call that the WG does not care. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Sep 15 08:29:39 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492E91A0699 for ; Mon, 15 Sep 2014 08:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eebmXH_Zc6M for ; Mon, 15 Sep 2014 08:29:33 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65741A6F2A for ; Mon, 15 Sep 2014 08:25:41 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVBcE9bD71geOSlcoZa9jSF5TunUtsv9J@postini.com; Mon, 15 Sep 2014 08:25:42 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s8FFPeFx002888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Sep 2014 11:25:40 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 15 Sep 2014 11:25:40 -0400 From: "Hollenbeck, Scott" To: Pete Resnick , "eppext@ietf.org" Thread-Topic: [eppext] AD Review of draft-ietf-eppext-reg-07 Thread-Index: AQHP0PgDD5oJxKo/10OnU/Ipp/DCupwCT3Tw Date: Mon, 15 Sep 2014 15:25:38 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494B3B74@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <54053671.9030409@qti.qualcomm.com> <541702BD.5080400@qti.qualcomm.com> In-Reply-To: <541702BD.5080400@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/6b6zLvMWmAZj4r8Yk-63h3sNp6U Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:29:38 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Pete Resnick > Sent: Monday, September 15, 2014 11:16 AM > To: eppext@ietf.org > Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07 >=20 > One silly issue that I missed: I note that this document is marked as > "Proposed Standard". My personal feeling is that creation of registries > can simply be done as an "Informational" document, though I don't think > it makes much difference. I can Last Call the document for Proposed > Standard anyway and let the IESG make the call (one of the few things > we > are empowered to do independently), but I wanted to check: Does anybody > care strongly one way or the other? If not, I'll note in the Last Call > that the WG does not care. I do not have a preference. Creation of the registry is the important thing= . Scott From nobody Tue Sep 16 17:09:51 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70551A6F5A; Tue, 16 Sep 2014 17:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcVtScJiI75o; Tue, 16 Sep 2014 17:09:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D611A00AE; Tue, 16 Sep 2014 17:09:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140917000944.24394.37414.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 17:09:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/7JsVqwxsxjV9dSltAEQnksrx3eE Cc: eppext@ietf.org Subject: [eppext] Last Call: (Extension Registry for the Extensible Provisioning Protocol) to Proposed Standard X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:09:46 -0000 The IESG has received a request from the Extensible Provisioning Protocol Extensions WG (eppext) to consider the following document: - 'Extension Registry for the Extensible Provisioning Protocol' 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 2014-09-30. 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 The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP and it specifies a format for an IANA registry to record those extensions. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Sep 17 04:17:14 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCFF1A6F58 for ; Tue, 16 Sep 2014 17:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Btquei5M0W6; Tue, 16 Sep 2014 17:09:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4230A1A00AE; Tue, 16 Sep 2014 17:09:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140917000946.24394.55399.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 17:09:46 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/NJI_ajoNtG3xyWTh7nrqffmF4ak X-Mailman-Approved-At: Wed, 17 Sep 2014 04:17:13 -0700 Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:09:48 -0000 Last call has been made for draft-ietf-eppext-reg and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Tue Sep 23 02:47:39 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3475E1A7008 for ; Tue, 23 Sep 2014 02:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.708 X-Spam-Level: X-Spam-Status: No, score=0.708 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIx-iao6Yksz for ; Tue, 23 Sep 2014 02:47:36 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502001A7007 for ; Tue, 23 Sep 2014 02:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:x-originating-ip; bh=ZQKBtjhA8JvaY1QwQwf34xduCVuTX1Lr7qZD/Ksk++M=; b=SCZw2O4k1dEBC4Am63OvRNDwhy/QU67bu975mWqNfiAOrF5IVJrl8xfSNr+85ikA/J+KbthDcj9zcRrRqeulR26jGnp0pBcrCPdVWNERdXvkhjBawCg02ZZWAGFnnCyVDRBMmeDKVgse/XZlizHwtnfiYKHeSkI3mqOS4uc5ATg= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id s8N9lYYK006208-s8N9lYYM006208 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 23 Sep 2014 11:47:34 +0200 Received: from [94.198.152.216] (94.198.152.216) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 23 Sep 2014 11:47:32 +0200 Message-ID: <542141B3.9020606@sidn.nl> Date: Tue, 23 Sep 2014 11:47:31 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.152.216] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/QnODabU_bL8BuU5060GO9BpqomI Subject: [eppext] EPPEXT @ Honolulu X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 09:47:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, So far the chairs received 3 requests to have an EPPEXT meeting @IETF91 in Honolulu, so we think it's wise to meet. We hope to have more than 5 participants, so could the silent members of the WG +1 if they plan to attend EPPEXT in Honolulu so we can request a proper meeting room? Or let us know if you plan to attend remotely. As for agenda items, please send them to the chairs if they don't show up in the proposed agenda below. We have identified a few issues on the list that were more or less fundamental and not for any particular WG document for f2f discussion. We intend to request for a 1,5 hour slot to have enough time to discuss, but I would like to ask for volunteers to present/summarize and lead these discussions: Agenda: 0. Welcome (Antoin 1 min.) 1. draft-ietf-eppext-reg (?? 5 min.) 2. Discussion: Is there sufficient consensus on current EPPEXT drafts for standards track, or should they be informational? (?? 10 min.) 3. draft-ietf-eppext-launchphase/draft-ietf-eppext-tmch-smd (?? 5 min.) 4. Discussion on protocol extension, object extension, or a command-response extension to progress draft-ietf-eppext-keyrelay (?? 20 min.) 5. draft-ietf-eppext-idnmap (?? 10 min.) 6. Discuss if we take on new work items/documents/extensions, recharter or close down (?? 10 min.) 7. AOB - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJUIUGzAAoJEDqHrM883Agnz7IH/3mtaHw8G6/RpXJ/AeNiF6OA 6xS3W1YsZcba4dep6BZpPKU8EcYvl1Twke6GQ/TMRCIPFDd/ty8Z+DmDFweXs5H4 SEcQ7n3RPKJ5NPcIKdmlbUIcovqV9Fgzn7bwHLNvAkidN/3HCv9EenwTuYwvSjSS GaauATqTKgpwwO7xRQ61ae7EV5jeyMZ6B1++MuIoYaYxvCuK6PTEjqN5kxHn2tmE aTjgrQxuvsySoQwYkKERCRUayJ0vQCFwZzevHKc4rzKaphj0ItOp1lHg/PTDb4dD PUANEa1Bgb77nbYKJqW9QMKxWLtyKXY51+QxL/rp7Uuo0dZow1eS5V21t3q++y8= =JT5T -----END PGP SIGNATURE----- From nobody Tue Sep 23 02:51:57 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31231A1A50 for ; Tue, 23 Sep 2014 02:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.618 X-Spam-Level: X-Spam-Status: No, score=-4.618 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQGLL5K5MjBl for ; Tue, 23 Sep 2014 02:51:55 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6401A1A75 for ; Tue, 23 Sep 2014 02:51:54 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Tue, 23 Sep 2014 11:51:52 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0195.001; Tue, 23 Sep 2014 11:51:49 +0200 From: Alexander Mayrhofer To: Antoin Verschuren , "eppext@ietf.org" Thread-Topic: [eppext] EPPEXT @ Honolulu Thread-Index: AQHP1xNuxIEFaCRpCEKyhZwQPj4wPJwOecFw Date: Tue, 23 Sep 2014 09:51:48 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0752688D53C@NICS-EXCH2.sbg.nic.at> References: <542141B3.9020606@sidn.nl> In-Reply-To: <542141B3.9020606@sidn.nl> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/-5dBa-Sqi0IpvA6PURuVcxkJ1Ws Subject: Re: [eppext] EPPEXT @ Honolulu X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 09:51:56 -0000 > So far the chairs received 3 requests to have an EPPEXT meeting > @IETF91 in Honolulu, so we think it's wise to meet. We hope to have more > than 5 participants, so could the silent members of the WG +1 if they pla= n to > attend EPPEXT in Honolulu so we can request a proper meeting room? > Or let us know if you plan to attend remotely. [Alexander Mayrhofer]=20 I will attend in person. From nobody Tue Sep 23 03:45:58 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026041A700D for ; Tue, 23 Sep 2014 03:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsxuvdiqAq4D for ; Tue, 23 Sep 2014 03:45:56 -0700 (PDT) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0931A7028 for ; Tue, 23 Sep 2014 03:45:53 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKVCFPYLDzCS8WVsLDM8sMUEKM3WX1YlpB@postini.com; Tue, 23 Sep 2014 03:45:55 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s8NAjpC6017077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Sep 2014 06:45:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 23 Sep 2014 06:45:51 -0400 From: "Hollenbeck, Scott" To: Antoin Verschuren , "eppext@ietf.org" Thread-Topic: [eppext] EPPEXT @ Honolulu Thread-Index: AQHP1xNreNH2ll6DPUuyhSlcezwBGpwOiKyQ Date: Tue, 23 Sep 2014 10:45:50 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F494C99E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <542141B3.9020606@sidn.nl> In-Reply-To: <542141B3.9020606@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/KU729WewCxwiTMHoSdYI8et674M Subject: Re: [eppext] EPPEXT @ Honolulu X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 10:45:58 -0000 > -----Original Message----- > From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Antoin > Verschuren > Sent: Tuesday, September 23, 2014 5:48 AM > To: eppext@ietf.org > Subject: [eppext] EPPEXT @ Honolulu >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Dear all, >=20 > So far the chairs received 3 requests to have an EPPEXT meeting > @IETF91 in Honolulu, so we think it's wise to meet. We hope to have > more than 5 participants, so could the silent members of the WG +1 if > they plan to attend EPPEXT in Honolulu so we can request a proper > meeting room? > Or let us know if you plan to attend remotely. I will attend in person. Scott From nobody Tue Sep 23 07:28:10 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68A21A854B for ; Tue, 23 Sep 2014 07:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfUUqW9wduh0 for ; Tue, 23 Sep 2014 07:28:02 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE321A86E0 for ; Tue, 23 Sep 2014 07:28:02 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 23 Sep 2014 07:27:58 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 23 Sep 2014 07:27:59 -0700 From: Edward Lewis To: "eppext@ietf.org" Thread-Topic: [eppext] EPPEXT @ Honolulu Thread-Index: AQHP1xN4D+kR1jrCM0i/z7KcAjB4PJwO7y0AgAAKGAA= Date: Tue, 23 Sep 2014 14:27:58 +0000 Message-ID: References: <542141B3.9020606@sidn.nl> <19F54F2956911544A32543B8A9BDE0752688D53C@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE0752688D53C@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [68.98.142.232] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3494312876_4262730" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/EnKFmCmaRqi7WsS2r4pgM_bCpjU Subject: Re: [eppext] EPPEXT @ Honolulu X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 14:28:09 -0000 --B_3494312876_4262730 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit metoo -----Original Message----- From: Alexander Mayrhofer Date: Tuesday, September 23, 2014 at 5:51 To: Antoin Verschuren , "eppext@ietf.org" Subject: Re: [eppext] EPPEXT @ Honolulu > So far the chairs received 3 requests to have an EPPEXT meeting > @IETF91 in Honolulu, so we think it's wise to meet. We hope to have more > than 5 participants, so could the silent members of the WG +1 if they >plan to > attend EPPEXT in Honolulu so we can request a proper meeting room? > Or let us know if you plan to attend remotely. [Alexander Mayrhofer] I will attend in person. _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --B_3494312876_4262730 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRVwNpSPInvYkHxbeDM xzhEGodrBzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5 MjMxNDI3NTZaMA0GCSqGSIb3DQEBAQUABIIBAKeuIT58VHtsSiQZDznqflhTjy4IPEKhrXb+ 2xbZzMwjGjajI5+vw9Xosx3K2LpgvnyanxuOfXBKWEz19FtnTPshjprQoLABXy424Crk2JbD 9CQCz2ifjl3uxuv3jPOGux9gjRRYBMIKhmiVRuy+gTag/5jHRsX83dM3Wq8oxM2eP2FrgGuj u3TIVM55/E/zzXBxtS1qgNpXq/aVA/EWnzfm36TQVA0gZDN8tezmvaLIpNd5E8cVrFnNcR0Q 6suSBr14xTLq3KvcMopaHEWK30AxUkUGz6lnJUt/5nX+lBuxSue5ks3yIJueSx9RxyPDr1hL mvTx1MdYLZz1D94IUkc= --B_3494312876_4262730-- From nobody Tue Sep 23 08:01:33 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5191B1A1B2A for ; Tue, 23 Sep 2014 08:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.687 X-Spam-Level: X-Spam-Status: No, score=-7.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drH3L981lM-p for ; Tue, 23 Sep 2014 08:01:30 -0700 (PDT) Received: from mail02.tor.cira.ca (mail02.tor.cira.ca [192.228.26.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1371A1B1F for ; Tue, 23 Sep 2014 08:01:30 -0700 (PDT) Received: from crp-spam-01.crp-dmz.cira.ca (mx1.cira.ca [192.228.22.116]) by mail02.tor.cira.ca (8.13.8/8.13.1) with ESMTP id s8NF1SoT015141; Tue, 23 Sep 2014 11:01:28 -0400 Received: from crp-spam-01.crp-dmz.cira.ca (localhost [127.0.0.1]) by crp-spam-01.crp-dmz.cira.ca (Postfix) with ESMTP id 54CDFACF96; Tue, 23 Sep 2014 11:01:28 -0400 (EDT) X-Virus-Scanned: by SpamTitan at corp.cira.ca; Received: from mx1.cira.ca (unknown [10.2.36.1]) by crp-spam-01.crp-dmz.cira.ca (Postfix) with ESMTP id 0F725ACF3D; Tue, 23 Sep 2014 11:01:28 -0400 (EDT) Received: from EXCH-02.CORP.CIRA.CA ([fe80::3c25:d5f2:72b8:e35c]) by EXCH-01.CORP.CIRA.CA ([fe80::2073:dbc0:bb14:ab50%19]) with mapi id 14.01.0438.000; Tue, 23 Sep 2014 11:01:27 -0400 From: Jacques Latour To: Antoin Verschuren , "eppext@ietf.org" Thread-Topic: [eppext] EPPEXT @ Honolulu Thread-Index: AQHP1xNsJBN16LOs9Eif8YoDqzT775wO0AdA Date: Tue, 23 Sep 2014 15:01:27 +0000 Message-ID: References: <542141B3.9020606@sidn.nl> In-Reply-To: <542141B3.9020606@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.40.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/9HVdcg4N1mAEaX0TcaPxvxDjnsg Subject: Re: [eppext] EPPEXT @ Honolulu X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 15:01:31 -0000 +1 in person > so could the silent members of the WG +1 if they plan to attend EPPEXT in= Honolulu=20 From nobody Wed Sep 24 06:36:13 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EDE1A00C0 for ; Wed, 24 Sep 2014 06:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.462 X-Spam-Level: ** X-Spam-Status: No, score=2.462 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EOBoOifUdc9 for ; Wed, 24 Sep 2014 06:36:07 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id C32761A00CD for ; Wed, 24 Sep 2014 06:36:06 -0700 (PDT) Received: from [192.168.2.102] (unknown [58.241.16.190]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMJC4yCJUK8AGAA--.13808S2; Wed, 24 Sep 2014 21:35:53 +0800 (CST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: <542141B3.9020606@sidn.nl> Date: Wed, 24 Sep 2014 21:35:51 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <542141B3.9020606@sidn.nl> To: Antoin Verschuren X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0ApMJC4yCJUK8AGAA--.13808S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAFyUAF1xZF48CFW8XF43Wrg_yoWrJF1UpF W8Ga45K3Z8tFWxCw4Iy3W7XF4YyrySvrZxJr90yw48JFZ8GFyUtrs2k3s5uryDCr4rJrWj vw4Y9ryq9a1DA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r4j6F4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_Xr4l42xK82IY c2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07b2fO7UUUUU= X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/lOJUwArvszF2MsD8kfjrAp7_E7E Cc: eppext@ietf.org Subject: Re: [eppext] EPPEXT @ Honolulu X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 13:36:09 -0000 Hi Antoin, I=A1=AFll attend in person. BTW, I wonder if I can apply a 10 minutes slot to discuss a new = extension for bundling. IMO, a generic bundling mechanism makes sense = for registries to handle not only IDN variants registration issue but = also same SLD registrations among several gTLDs. I=A1=AFm writing a = draft on this topic and going to submit it in several weeks. Although I know working on other new extensions is out of scope of the = current WG=A1=AFs charter, I still hope I can get a F2F chance to = discuss this idea. My only intent is to get F2F feedbacks from the WG = which I think is the only appropriate Working Group to present and = discuss this kind of issue. Furthermore, I=A1=AFm curious if in future more new ideas of proposing = new extensions want to be F2F discussed by the EPP community before = formally submit to the Extension Registry for the EPP, do you guys think = is it necessary for the WG to provide such opportunity before really = closing itself? IMHO, it=A1=AFs better that if the WG can remain to be = alive and provide helps for several new extensions for some time even = after finishing all the milestones of the current charter. Cheers, Ning =D4=DA 2014=C4=EA9=D4=C223=C8=D5=A3=AC=CF=C2=CE=E75:47=A3=ACAntoin = Verschuren =D0=B4=B5=C0=A3=BA > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Dear all, >=20 > So far the chairs received 3 requests to have an EPPEXT meeting > @IETF91 in Honolulu, so we think it's wise to meet. We hope to have > more than 5 participants, so could the silent members of the WG +1 if > they plan to attend EPPEXT in Honolulu so we can request a proper > meeting room? > Or let us know if you plan to attend remotely. >=20 > As for agenda items, please send them to the chairs if they don't show > up in the proposed agenda below. >=20 > We have identified a few issues on the list that were more or less > fundamental and not for any particular WG document for f2f discussion. > We intend to request for a 1,5 hour slot to have enough time to > discuss, but I would like to ask for volunteers to present/summarize > and lead these discussions: >=20 > Agenda: >=20 > 0. Welcome (Antoin 1 min.) >=20 > 1. draft-ietf-eppext-reg (?? 5 min.) >=20 > 2. Discussion: Is there sufficient consensus on current EPPEXT drafts > for standards track, or should they be informational? (?? 10 min.) >=20 > 3. draft-ietf-eppext-launchphase/draft-ietf-eppext-tmch-smd (?? 5 = min.) >=20 > 4. Discussion on protocol extension, object extension, or a > command-response extension to progress draft-ietf-eppext-keyrelay (?? > 20 min.) >=20 > 5. draft-ietf-eppext-idnmap (?? 10 min.) >=20 > 6. Discuss if we take on new work items/documents/extensions, > recharter or close down (?? 10 min.) >=20 > 7. AOB >=20 >=20 >=20 > - --=20 > Antoin Verschuren >=20 > Technical Policy Advisor SIDN > Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands >=20 > P: +31 26 3525500 M: +31 6 23368970 > Mailto: antoin.verschuren@sidn.nl > XMPP: antoin.verschuren@jabber.sidn.nl > HTTP://www.sidn.nl/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQEcBAEBAgAGBQJUIUGzAAoJEDqHrM883Agnz7IH/3mtaHw8G6/RpXJ/AeNiF6OA > 6xS3W1YsZcba4dep6BZpPKU8EcYvl1Twke6GQ/TMRCIPFDd/ty8Z+DmDFweXs5H4 > SEcQ7n3RPKJ5NPcIKdmlbUIcovqV9Fgzn7bwHLNvAkidN/3HCv9EenwTuYwvSjSS > GaauATqTKgpwwO7xRQ61ae7EV5jeyMZ6B1++MuIoYaYxvCuK6PTEjqN5kxHn2tmE > aTjgrQxuvsySoQwYkKERCRUayJ0vQCFwZzevHKc4rzKaphj0ItOp1lHg/PTDb4dD > PUANEa1Bgb77nbYKJqW9QMKxWLtyKXY51+QxL/rp7Uuo0dZow1eS5V21t3q++y8=3D > =3DJT5T > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext From nobody Wed Sep 24 13:06:05 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB451A0AF8 for ; Wed, 24 Sep 2014 13:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWtPLjigqCKQ for ; Wed, 24 Sep 2014 13:05:59 -0700 (PDT) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E4D1A0394 for ; Wed, 24 Sep 2014 13:05:54 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKVCMkIXxUU/4wF7RM6evh1HJ3cADwdZ5L@postini.com; Wed, 24 Sep 2014 13:05:58 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s8OK5pPU017896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 16:05:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 24 Sep 2014 16:05:51 -0400 From: "Gould, James" To: Ning Kong Thread-Topic: [eppext] EPPEXT @ Honolulu Thread-Index: AQHP1xNrh4dFyz+ZW0eDNnkeYpG7gpwQjdGAgABs9QA= Date: Wed, 24 Sep 2014 20:05:51 +0000 Message-ID: References: <542141B3.9020606@sidn.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_D4F79DBB07CB4DA7AF369F74FCBFF1D5verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/KWFhSSZzRRzOile8wmxKs7eOOr8 Cc: Antoin Verschuren , "eppext@ietf.org" Subject: Re: [eppext] EPPEXT @ Honolulu X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 20:06:03 -0000 --_004_D4F79DBB07CB4DA7AF369F74FCBFF1D5verisigncom_ Content-Type: multipart/alternative; boundary="_000_D4F79DBB07CB4DA7AF369F74FCBFF1D5verisigncom_" --_000_D4F79DBB07CB4DA7AF369F74FCBFF1D5verisigncom_ Content-Type: text/plain; charset="GB18030" Content-Transfer-Encoding: quoted-printable Ning, We may want to collaborate on the bundling extension that you=A1=AFre refer= ring to. We have a custom Related Domain EPP Extension ( http://www.verisi= gninc.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html ) t= hat looks to solve the same or similar problem. I will be at IETF-91, so i= f there is no time to bring up new extensions at the EPPEXT meeting, we cou= ld setup a time to discuss this extension f2f. Others from the WG can part= icipate in the f2f if there is interest. Collaborating on like or overlapping extensions that can be combined, and t= hat may eventually mature up the IETF standards process, is a good example = of the purpose of the Registration Operations Industry Association. The Re= gistration Operation Industry Association will be discussed on Thursday, Oc= tober 16th, during the week of ICANN 51 in LA. Please see Scott Hollenbeck= =A1=AFs blog postings ( http://www.circleid.com/posts/20140919_is_it_time_f= or_registration_operations_industry_association_part_3/ ) for more informat= ion. Thanks, =A1=AA JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Sep 24, 2014, at 9:35 AM, Ning Kong > wrote: Hi Antoin, I=A1=AFll attend in person. BTW, I wonder if I can apply a 10 minutes slot to discuss a new extension f= or bundling. IMO, a generic bundling mechanism makes sense for registries t= o handle not only IDN variants registration issue but also same SLD registr= ations among several gTLDs. I=A1=AFm writing a draft on this topic and goin= g to submit it in several weeks. Although I know working on other new extensions is out of scope of the curr= ent WG=A1=AFs charter, I still hope I can get a F2F chance to discuss this = idea. My only intent is to get F2F feedbacks from the WG which I think is t= he only appropriate Working Group to present and discuss this kind of issue= . Furthermore, I=A1=AFm curious if in future more new ideas of proposing new = extensions want to be F2F discussed by the EPP community before formally su= bmit to the Extension Registry for the EPP, do you guys think is it necessa= ry for the WG to provide such opportunity before really closing itself? IMH= O, it=A1=AFs better that if the WG can remain to be alive and provide helps= for several new extensions for some time even after finishing all the mile= stones of the current charter. Cheers, Ning =D4=DA 2014=C4=EA9=D4=C223=C8=D5=A3=AC=CF=C2=CE=E75:47=A3=ACAntoin Verschur= en > =D0=B4=B5= =C0=A3=BA -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, So far the chairs received 3 requests to have an EPPEXT meeting @IETF91 in Honolulu, so we think it's wise to meet. We hope to have more than 5 participants, so could the silent members of the WG +1 if they plan to attend EPPEXT in Honolulu so we can request a proper meeting room? Or let us know if you plan to attend remotely. As for agenda items, please send them to the chairs if they don't show up in the proposed agenda below. We have identified a few issues on the list that were more or less fundamental and not for any particular WG document for f2f discussion. We intend to request for a 1,5 hour slot to have enough time to discuss, but I would like to ask for volunteers to present/summarize and lead these discussions: Agenda: 0. Welcome (Antoin 1 min.) 1. draft-ietf-eppext-reg (?? 5 min.) 2. Discussion: Is there sufficient consensus on current EPPEXT drafts for standards track, or should they be informational? (?? 10 min.) 3. draft-ietf-eppext-launchphase/draft-ietf-eppext-tmch-smd (?? 5 min.) 4. Discussion on protocol extension, object extension, or a command-response extension to progress draft-ietf-eppext-keyrelay (?? 20 min.) 5. draft-ietf-eppext-idnmap (?? 10 min.) 6. Discuss if we take on new work items/documents/extensions, recharter or close down (?? 10 min.) 7. AOB - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJUIUGzAAoJEDqHrM883Agnz7IH/3mtaHw8G6/RpXJ/AeNiF6OA 6xS3W1YsZcba4dep6BZpPKU8EcYvl1Twke6GQ/TMRCIPFDd/ty8Z+DmDFweXs5H4 SEcQ7n3RPKJ5NPcIKdmlbUIcovqV9Fgzn7bwHLNvAkidN/3HCv9EenwTuYwvSjSS GaauATqTKgpwwO7xRQ61ae7EV5jeyMZ6B1++MuIoYaYxvCuK6PTEjqN5kxHn2tmE aTjgrQxuvsySoQwYkKERCRUayJ0vQCFwZzevHKc4rzKaphj0ItOp1lHg/PTDb4dD PUANEa1Bgb77nbYKJqW9QMKxWLtyKXY51+QxL/rp7Uuo0dZow1eS5V21t3q++y8=3D =3DJT5T -----END PGP SIGNATURE----- _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_D4F79DBB07CB4DA7AF369F74FCBFF1D5verisigncom_ Content-Type: text/html; charset="GB18030" Content-ID: <4BD13C0E2B009E4D86BE4E337E1A555D@verisign.com> Content-Transfer-Encoding: quoted-printable Ning,

We may want to collaborate on the bundling extension that you=A1=AFre = referring to.  We have a custom Related Domain EPP Extension ( http://www.verisigninc.com/assets/epp-sdk/verisign_= epp-extension_related-domain_v00.html ) that looks to solve the same or similar problem.  I will be at IETF-9= 1, so if there is no time to bring up new extensions at the EPPEXT meeting,= we could setup a time to discuss this extension f2f.  Others from the= WG can participate in the f2f if there is interest.  

Collaborating on like or overlapping extensions that can be combined, = and that may eventually mature up the IETF standards process, is a good exa= mple of the purpose of the Registration Operations Industry Association. &n= bsp;The Registration Operation Industry Association will be discussed on Thursday, October 16th, during the week o= f ICANN 51 in LA.  Please see Scott Hollenbeck=A1=AFs blog postings (&= nbsp;http://www.circleid.com/po= sts/20140919_is_it_time_for_registration_operations_industry_association_pa= rt_3/ ) for more information.

Thanks,

=A1=AA

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Principal Software Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Sep 24, 2014, at 9:35 AM, Ning Kong <nkong@cnnic.cn> wrote:


Hi Antoin,

I=A1=AFll attend in person.

BTW, I wonder if I can apply a 10 minutes slot to discuss a new extension f= or bundling. IMO, a generic bundling mechanism makes sense for registries t= o handle not only IDN variants registration issue but also same SLD registr= ations among several gTLDs. I=A1=AFm writing a draft on this topic and going to submit it in several weeks.

Although I know working on other new extensions is out of scope of the curr= ent WG=A1=AFs charter, I still hope I can get a F2F chance to discuss this = idea. My only intent is to get F2F feedbacks from the WG which I think is t= he only appropriate Working Group to present and discuss this kind of issue.

Furthermore, I=A1=AFm curious if in future more new ideas of proposing new = extensions want to be F2F discussed by the EPP community before formally su= bmit to the Extension Registry for the EPP, do you guys think is it necessa= ry for the WG to provide such opportunity before really closing itself? IMHO, it=A1=AFs better that if the WG can re= main to be alive and provide helps for several new extensions for some time= even after finishing all the milestones of the current charter.


Cheers,
Ning



=D4=DA 2014=C4=EA9=D4=C223=C8=D5=A3=AC=CF=C2=CE=E75:47=A3=ACAntoin Verschur= en <antoin.verschuren@sidn.= nl> =D0=B4=B5=C0=A3=BA

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all,

So far the chairs received 3 requests to have an EPPEXT meeting
@IETF91 in Honolulu, so we think it's wise to meet. We hope to have
more than 5 participants, so could the silent members of the WG +1 if they plan to attend EPPEXT in Honolulu so we can request a proper
meeting room?
Or let us know if you plan to attend remotely.

As for agenda items, please send them to the chairs if they don't show
up in the proposed agenda below.

We have identified a few issues on the list that were more or less
fundamental and not for any particular WG document for f2f discussion.
We intend to request for a 1,5 hour slot to have enough time to
discuss, but I would like to ask for volunteers to present/summarize
and lead these discussions:

Agenda:

0. Welcome (Antoin 1 min.)

1. draft-ietf-eppext-reg (?? 5 min.)

2. Discussion: Is there sufficient consensus on current EPPEXT drafts
for standards track, or should they be informational? (?? 10 min.)

3. draft-ietf-eppext-launchphase/draft-ietf-eppext-tmch-smd (?? 5 min.)

4. Discussion on protocol extension, object extension, or a
command-response extension to progress draft-ietf-eppext-keyrelay (??
20 min.)

5. draft-ietf-eppext-idnmap (?? 10 min.)

6. Discuss if we take on new work items/documents/extensions,
recharter or close down (?? 10 min.)

7. AOB



- --
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: antoin.verschuren@sidn= .nl
XMPP: antoin.verschuren= @jabber.sidn.nl
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJUIUGzAAoJEDqHrM883Agnz7IH/3mtaHw8G6/RpXJ/AeNiF6OA
6xS3W1YsZcba4dep6BZpPKU8EcYvl1Twke6GQ/TMRCIPFDd/ty8Z+DmDFweXs5H4
SEcQ7n3RPKJ5NPcIKdmlbUIcovqV9Fgzn7bwHLNvAkidN/3HCv9EenwTuYwvSjSS
GaauATqTKgpwwO7xRQ61ae7EV5jeyMZ6B1++MuIoYaYxvCuK6PTEjqN5kxHn2tmE aTjgrQxuvsySoQwYkKERCRUayJ0vQCFwZzevHKc4rzKaphj0ItOp1lHg/PTDb4dD
PUANEa1Bgb77nbYKJqW9QMKxWLtyKXY51+QxL/rp7Uuo0dZow1eS5V21t3q++y8= =3D
=3DJT5T
-----END PGP SIGNATURE-----

_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/eppext


_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/eppext

--_000_D4F79DBB07CB4DA7AF369F74FCBFF1D5verisigncom_-- --_004_D4F79DBB07CB4DA7AF369F74FCBFF1D5verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Wed, 24 Sep 2014 20:05:51 GMT"; modification-date="Wed, 24 Sep 2014 20:05:51 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_D4F79DBB07CB4DA7AF369F74FCBFF1D5verisigncom_-- From nobody Thu Sep 25 02:01:05 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9B51A1BEA for ; Thu, 25 Sep 2014 02:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-KoyQofP1wy for ; Thu, 25 Sep 2014 02:00:57 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 054F91A02F0 for ; Thu, 25 Sep 2014 02:00:56 -0700 (PDT) Received: from [172.16.2.39] (unknown [58.214.238.218]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CZoJDD2SNUt_wGAA--.14532S2; Thu, 25 Sep 2014 17:00:52 +0800 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8D79C869-0623-4161-8DDF-E33FBF08598A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ning Kong In-Reply-To: Date: Thu, 25 Sep 2014 17:00:50 +0800 Message-Id: References: <542141B3.9020606@sidn.nl> To: "Gould, James" X-Mailer: Apple Mail (2.1878.6) X-CM-TRANSID: AQAAf0CZoJDD2SNUt_wGAA--.14532S2 X-Coremail-Antispam: 1UD129KBjvJXoWxtFy7tFy3GF1kuF1xAryUtrb_yoW7Ww4rpF WIg34fKw1DtF1xJw1Ivw1UXr4YvrySv3y3Jr98tw4jyF9xCFyUtr4Ik345ZryUGr4rJryj vw4UuryDWa17AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkYb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21lYx0E2Ix0cI8I cVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r4j6F4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjc xG0xvY0x0EwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6r4fMxAIw28IcxkI 7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxV Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY 6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6x AIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280 aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU8dWrJUUUUU== X-CM-SenderInfo: xqnr0ww6fq0xffof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/oWWF0BjXWWep3ZO0DMTl427hqQU Cc: Antoin Verschuren , "eppext@ietf.org" Subject: Re: [eppext] EPPEXT @ Honolulu X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 09:01:00 -0000 --Apple-Mail=_8D79C869-0623-4161-8DDF-E33FBF08598A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=gb18030 Hi James, > We may want to collaborate on the bundling extension that you=A1=AFre = referring to. We have a custom Related Domain EPP Extension ( = http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_related-d= omain_v00.html ) that looks to solve the same or similar problem. I = will be at IETF-91, so if there is no time to bring up new extensions at = the EPPEXT meeting, we could setup a time to discuss this extension f2f. = Others from the WG can participate in the f2f if there is interest. =20 Thanks for your interest on the bundling extension. I=A1=AFll read the = document you provided and discuss with you later. I=A1=AFd like to talk = with you and more interested people on this topic at IETF 91. =20 > Collaborating on like or overlapping extensions that can be combined, = and that may eventually mature up the IETF standards process, is a good = example of the purpose of the Registration Operations Industry = Association. The Registration Operation Industry Association will be = discussed on Thursday, October 16th, during the week of ICANN 51 in LA. = Please see Scott Hollenbeck=A1=AFs blog postings ( = http://www.circleid.com/posts/20140919_is_it_time_for_registration_operati= ons_industry_association_part_3/ ) for more information. Thanks for your info. I=A1=AFll participate remotely and keep on = following this activity.=20 Cheers, Ning > On Sep 24, 2014, at 9:35 AM, Ning Kong wrote: >=20 >>=20 >> Hi Antoin, >>=20 >> I=A1=AFll attend in person. >>=20 >> BTW, I wonder if I can apply a 10 minutes slot to discuss a new = extension for bundling. IMO, a generic bundling mechanism makes sense = for registries to handle not only IDN variants registration issue but = also same SLD registrations among several gTLDs. I=A1=AFm writing a = draft on this topic and going to submit it in several weeks. >>=20 >> Although I know working on other new extensions is out of scope of = the current WG=A1=AFs charter, I still hope I can get a F2F chance to = discuss this idea. My only intent is to get F2F feedbacks from the WG = which I think is the only appropriate Working Group to present and = discuss this kind of issue. >>=20 >> Furthermore, I=A1=AFm curious if in future more new ideas of = proposing new extensions want to be F2F discussed by the EPP community = before formally submit to the Extension Registry for the EPP, do you = guys think is it necessary for the WG to provide such opportunity before = really closing itself? IMHO, it=A1=AFs better that if the WG can remain = to be alive and provide helps for several new extensions for some time = even after finishing all the milestones of the current charter. >>=20 >>=20 >> Cheers, >> Ning >>=20 >>=20 >>=20 >> =D4=DA 2014=C4=EA9=D4=C223=C8=D5=A3=AC=CF=C2=CE=E75:47=A3=ACAntoin = Verschuren =D0=B4=B5=C0=A3=BA >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>>=20 >>> Dear all, >>>=20 >>> So far the chairs received 3 requests to have an EPPEXT meeting >>> @IETF91 in Honolulu, so we think it's wise to meet. We hope to have >>> more than 5 participants, so could the silent members of the WG +1 = if >>> they plan to attend EPPEXT in Honolulu so we can request a proper >>> meeting room? >>> Or let us know if you plan to attend remotely. >>>=20 >>> As for agenda items, please send them to the chairs if they don't = show >>> up in the proposed agenda below. >>>=20 >>> We have identified a few issues on the list that were more or less >>> fundamental and not for any particular WG document for f2f = discussion. >>> We intend to request for a 1,5 hour slot to have enough time to >>> discuss, but I would like to ask for volunteers to present/summarize >>> and lead these discussions: >>>=20 >>> Agenda: >>>=20 >>> 0. Welcome (Antoin 1 min.) >>>=20 >>> 1. draft-ietf-eppext-reg (?? 5 min.) >>>=20 >>> 2. Discussion: Is there sufficient consensus on current EPPEXT = drafts >>> for standards track, or should they be informational? (?? 10 min.) >>>=20 >>> 3. draft-ietf-eppext-launchphase/draft-ietf-eppext-tmch-smd (?? 5 = min.) >>>=20 >>> 4. Discussion on protocol extension, object extension, or a >>> command-response extension to progress draft-ietf-eppext-keyrelay = (?? >>> 20 min.) >>>=20 >>> 5. draft-ietf-eppext-idnmap (?? 10 min.) >>>=20 >>> 6. Discuss if we take on new work items/documents/extensions, >>> recharter or close down (?? 10 min.) >>>=20 >>> 7. AOB >>>=20 >>>=20 >>>=20 >>> - --=20 >>> Antoin Verschuren >>>=20 >>> Technical Policy Advisor SIDN >>> Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands >>>=20 >>> P: +31 26 3525500 M: +31 6 23368970 >>> Mailto: antoin.verschuren@sidn.nl >>> XMPP: antoin.verschuren@jabber.sidn.nl >>> HTTP://www.sidn.nl/ >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (GNU/Linux) >>>=20 >>> iQEcBAEBAgAGBQJUIUGzAAoJEDqHrM883Agnz7IH/3mtaHw8G6/RpXJ/AeNiF6OA >>> 6xS3W1YsZcba4dep6BZpPKU8EcYvl1Twke6GQ/TMRCIPFDd/ty8Z+DmDFweXs5H4 >>> SEcQ7n3RPKJ5NPcIKdmlbUIcovqV9Fgzn7bwHLNvAkidN/3HCv9EenwTuYwvSjSS >>> GaauATqTKgpwwO7xRQ61ae7EV5jeyMZ6B1++MuIoYaYxvCuK6PTEjqN5kxHn2tmE >>> aTjgrQxuvsySoQwYkKERCRUayJ0vQCFwZzevHKc4rzKaphj0ItOp1lHg/PTDb4dD >>> PUANEa1Bgb77nbYKJqW9QMKxWLtyKXY51+QxL/rp7Uuo0dZow1eS5V21t3q++y8=3D >>> =3DJT5T >>> -----END PGP SIGNATURE----- >>>=20 >>> _______________________________________________ >>> EppExt mailing list >>> EppExt@ietf.org >>> https://www.ietf.org/mailman/listinfo/eppext >>=20 >>=20 >> _______________________________________________ >> EppExt mailing list >> EppExt@ietf.org >> https://www.ietf.org/mailman/listinfo/eppext >=20 > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext --Apple-Mail=_8D79C869-0623-4161-8DDF-E33FBF08598A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=gb18030

Hi = James,

We may want to collaborate on the bundling extension that you=A1=AFre= referring to.  We have a custom Related Domain EPP Extension = ( http://www.verisigninc.com/assets/epp-sdk/verisign= _epp-extension_related-domain_v00.html ) that looks to solve the same or similar problem.  I will be at = IETF-91, so if there is no time to bring up new extensions at the EPPEXT = meeting, we could setup a time to discuss this extension f2f. =  Others from the WG can participate in the f2f if there is interest.  
Thanks for your interest = on the bundling extension. I=A1=AFll read the document you provided and = discuss with you later. I=A1=AFd like to talk with you and more = interested people on this topic at IETF 91.  

Collaborating on like or overlapping extensions that can be = combined, and that may eventually mature up the IETF standards process, = is a good example of the purpose of the Registration Operations Industry = Association.  The Registration Operation Industry Association will be discussed on Thursday, October 16th, during the = week of ICANN 51 in LA.  Please see Scott Hollenbeck=A1=AFs blog = postings ( http://www.circleid.com/posts/20= 140919_is_it_time_for_registration_operations_industry_association_part_3/=  ) for more information.
Thanks for your info. = I=A1=AFll participate remotely and keep on following this = activity. 

Cheers,
Ning

On Sep 24, 2014, at 9:35 AM, Ning Kong <nkong@cnnic.cn> wrote:


Hi Antoin,

I=A1=AFll attend in person.

BTW, I wonder if I can apply a 10 minutes slot to discuss a new = extension for bundling. IMO, a generic bundling mechanism makes sense = for registries to handle not only IDN variants registration issue but = also same SLD registrations among several gTLDs. I=A1=AFm writing a draft on this topic and going to submit it in several = weeks.

Although I know working on other new extensions is out of scope of the = current WG=A1=AFs charter, I still hope I can get a F2F chance to = discuss this idea. My only intent is to get F2F feedbacks from the WG = which I think is the only appropriate Working Group to present and discuss this kind of issue.

Furthermore, I=A1=AFm curious if in future more new ideas of proposing = new extensions want to be F2F discussed by the EPP community before = formally submit to the Extension Registry for the EPP, do you guys think = is it necessary for the WG to provide such opportunity before really closing itself? IMHO, it=A1=AFs better that if the WG can = remain to be alive and provide helps for several new extensions for some = time even after finishing all the milestones of the current charter.


Cheers,
Ning



=D4=DA 2014=C4=EA9=D4=C223=C8=D5=A3=AC=CF=C2=CE=E75:47=A3=ACAntoin = Verschuren <antoin.verschuren@sidn.nl>= ; =D0=B4=B5=C0=A3=BA

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all,

So far the chairs received 3 requests to have an EPPEXT meeting
@IETF91 in Honolulu, so we think it's wise to meet. We hope to have
more than 5 participants, so could the silent members of the WG +1 = if
they plan to attend EPPEXT in Honolulu so we can request a proper
meeting room?
Or let us know if you plan to attend remotely.

As for agenda items, please send them to the chairs if they don't = show
up in the proposed agenda below.

We have identified a few issues on the list that were more or less
fundamental and not for any particular WG document for f2f = discussion.
We intend to request for a 1,5 hour slot to have enough time to
discuss, but I would like to ask for volunteers to present/summarize
and lead these discussions:

Agenda:

0. Welcome (Antoin 1 min.)

1. draft-ietf-eppext-reg (?? 5 min.)

2. Discussion: Is there sufficient consensus on current EPPEXT = drafts
for standards track, or should they be informational? (?? 10 min.)

3. draft-ietf-eppext-launchphase/draft-ietf-eppext-tmch-smd (?? 5 = min.)

4. Discussion on protocol extension, object extension, or a
command-response extension to progress draft-ietf-eppext-keyrelay = (??
20 min.)

5. draft-ietf-eppext-idnmap (?? 10 min.)

6. Discuss if we take on new work items/documents/extensions,
recharter or close down (?? 10 min.)

7. AOB



- --
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.= sidn.nl
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJUIUGzAAoJEDqHrM883Agnz7IH/3mtaHw8G6/RpXJ/AeNiF6OA
6xS3W1YsZcba4dep6BZpPKU8EcYvl1Twke6GQ/TMRCIPFDd/ty8Z+DmDFweXs5H4
SEcQ7n3RPKJ5NPcIKdmlbUIcovqV9Fgzn7bwHLNvAkidN/3HCv9EenwTuYwvSjSS
GaauATqTKgpwwO7xRQ61ae7EV5jeyMZ6B1++MuIoYaYxvCuK6PTEjqN5kxHn2tmE
aTjgrQxuvsySoQwYkKERCRUayJ0vQCFwZzevHKc4rzKaphj0ItOp1lHg/PTDb4dD
PUANEa1Bgb77nbYKJqW9QMKxWLtyKXY51+QxL/rp7Uuo0dZow1eS5V21t3q++y8=3D
=3DJT5T
-----END PGP SIGNATURE-----

_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org= /mailman/listinfo/eppext


_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org= /mailman/listinfo/eppext

_______________________________________________
EppExt mailing = list
EppExt@ietf.org
https://www.ietf.or= g/mailman/listinfo/eppext

= --Apple-Mail=_8D79C869-0623-4161-8DDF-E33FBF08598A-- From nobody Thu Sep 25 05:42:13 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CF51A6FDF; Thu, 25 Sep 2014 05:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGWXvjkGjj70; Thu, 25 Sep 2014 05:42:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B73181A000C; Thu, 25 Sep 2014 05:42:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140925124208.11124.78122.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 05:42:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/sU2XI26DlZb5lxCPSoIUITmwsq4 Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-launchphase-02.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:42:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Provisioning Protocol Extensions Working Group of the IETF. Title : Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) Authors : James Gould Wil Tan Gavin Brown Filename : draft-ietf-eppext-launchphase-02.txt Pages : 52 Date : 2014-09-25 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-launchphase/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-launchphase-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-launchphase-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 25 08:00:26 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB7C1A7028 for ; Thu, 25 Sep 2014 08:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzIshTEDZU03 for ; Thu, 25 Sep 2014 08:00:17 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE531A0172 for ; Thu, 25 Sep 2014 08:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:x-originating-ip; bh=wS6i/nG9ec5rvXxKXyXub8rzB5hyGcs3ewDIMtojH/Q=; b=E/w4SNckGwPNJRXYkE1ggFtPbK5qelk9lfBK5VBJU2o3z3TTGJJSY/W9rAjqt8eDV/hOXBKiXgi0bk4JtV/sFNPOz6z/h0HDx1JQQetQG2bVvtFdNPgRol3P9VL+XNkNyi5vr8lEpcvSloWo4/OKtCjUA4mibpAkDFa6keDASog= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id s8PF0FFh017156-s8PF0FFj017156 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 25 Sep 2014 17:00:15 +0200 Received: from rndhost215.sidn.nl (94.198.152.215) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 25 Sep 2014 17:00:11 +0200 Message-ID: <54242DFA.5080000@sidn.nl> Date: Thu, 25 Sep 2014 17:00:10 +0200 From: "Marco Davids (SIDN)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: References: <542141B3.9020606@sidn.nl> In-Reply-To: <542141B3.9020606@sidn.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090000020205090000050609" X-Originating-IP: [94.198.152.215] Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/5-8TYQclG2eZC5TnmeN7NEOyYWM Subject: Re: [eppext] EPPEXT @ Honolulu X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 15:00:19 -0000 --------------ms090000020205090000050609 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 23/09/14 11:47, Antoin Verschuren wrote: > so could the silent members of the WG +1 if > they plan to attend EPPEXT in Honolulu so we can request a proper > meeting room? Or let us know if you plan to attend remotely. +1 in person. --=20 Marco --------------ms090000020205090000050609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMZjCC BiowggUSoAMCAQICAwoD4zANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDUyMDE3NTUyOFoXDTE1MDUyMjAwMTc1NlowRDEdMBsGA1UE AwwUbWFyY28uZGF2aWRzQHNpZG4ubmwxIzAhBgkqhkiG9w0BCQEWFG1hcmNvLmRhdmlkc0Bz aWRuLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0tDXTB0Q5LVXcdRfAg/x 7Baw83FDEtt566NEjxSG0Q6xnexJtiXUl4bfGSE9PHN2Y9tT7NOGxXPNPjddChUJbKwGhH27 zmWA6LK/4AnNyew8seFGKMp3UFOkfVUGBcNPvtHQPDSAZnZuds50vhpqLqyxa+EA8rjttC93 8/dZAjjV7etpk24W1s/Ith+c5oSP6rqIfl+tUPc4s2ZOudq8ov6jAV2OQ53S/G1OFR9s9ZEl uYZohI2gQB7Fz5Xfij20YqWnZ9619JndU4b5Cqs4NCxhnO3Pgoba85LhVdvkxAbKq/cIv8zP 4FrsKUhdkjWBmWK+r+vU/GtdcmZkM2YCtQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADALBgNV HQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTVD7Di X5HtXqiaF+DhqGiH2ixl1TAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HREEGDAWgRRtYXJjby5kYXZpZHNAc2lkbi5ubDCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYB BAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp Y3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0 aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21w bGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAGjmOZpe/qYtBZy5VSP5JRKEKlwIpxGUDNQv YhvCp53aVXvALQmXO6X1v3Oia+hpMliCof9ymQXUCSfNaftKBYx4ROr6kgmVZUtTrb10f/eW xNDVV/5Jhy1mAyQ4ziMXoW7r8Mbji653p2ewbYLZd6mtXkzvM/SNdh4iG5+dD4x2ih9IzEl6 XO4WFTgNFu26/0YXSCzkyb3K3O2jAUzyHvYB4dMUjxryVNDcLPae1CxeAYgpZNNmUVZPiOyB Fr/NRKgC77X1Q2STwUbo8JTTXka/rZup1Huj2g2AMrBZ/fO8+HSWFF0OeioEWFvOpSc2c8hs cb8LAWbtf9XerJ/a1rgwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zP f1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG /FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSy rrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIB qTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUH AQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYB BQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCeg JaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBm MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqG SIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95 CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A +hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcL N5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/ O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI27 0g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z 77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/Q vVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8 BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoD4zAJBgUrDgMCGgUAoIIC HTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MjUxNTAw MTBaMCMGCSqGSIb3DQEJBDEWBBSNJiOJA9HJChfbIvG2MtcaRqlDzDBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3 EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCgPjMIGnBgsq hkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMK A+MwDQYJKoZIhvcNAQEBBQAEggEAa8ihLfFadFl7+gOi0YG+msXO55hfG5bmfRHCgxhX5VIw d1tay9aYx/r8OeDLqNNFMvsDLu1r2BGd0PM4b7uPDx+rlgot59pW1+tXpxS3Mf+px63fkRc3 HuyyC8ESID3AY8KLODVUbdh/WDOz0LUMCzwkDrgzAn1nZncXYjzeM90/Df/PIve8a9fBZ1vp C/wdUtp+0KfbvTnYTbJFD16tOz6qPVSzUdF682KA2eFAtt90s+6RA7JR/+5ZdrN2jm1cJHi2 HhYHQjIv4sephi7eMyrYNRR1hiYmEv7s7tajjbIssOCjSJJByUcN8J+N5uq5oEloFJsr6IQG 6yUQl1+E6AAAAAAAAA== --------------ms090000020205090000050609-- From nobody Thu Sep 25 18:06:32 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B933C1A0158 for ; Thu, 25 Sep 2014 18:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATCGhf3slEim; Thu, 25 Sep 2014 18:06:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 809C61A0007; Thu, 25 Sep 2014 18:06:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140926010629.11722.55171.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 18:06:29 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/7bQcO5vA8nNWaHkJmWLR4zYlnYc Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 01:06:31 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Mon Sep 29 09:11:53 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDD01A8846 for ; Mon, 29 Sep 2014 09:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph8Whizjx2eP for ; Mon, 29 Sep 2014 09:11:49 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100011A8824 for ; Mon, 29 Sep 2014 09:11:48 -0700 (PDT) Received: from Gavins-MacBook-Pro.local (unknown [217.138.20.162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 3B1239E81 for ; Mon, 29 Sep 2014 16:11:47 +0000 (UTC) Message-ID: <542984C2.6030102@centralnic.com> Date: Mon, 29 Sep 2014 17:11:46 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: eppext@ietf.org References: <20140929135220.7395.85844.idtracker@ietfa.amsl.com> In-Reply-To: <20140929135220.7395.85844.idtracker@ietfa.amsl.com> OpenPGP: id=F923B4CE X-Forwarded-Message-Id: <20140929135220.7395.85844.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F8xT4Wf94k7QhaKJwvxELUJg4TCj9k81s" Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/x9yWw_WoZWR6YYz3GwVg01qjOyQ Subject: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-03.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:11:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F8xT4Wf94k7QhaKJwvxELUJg4TCj9k81s Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I've just published a new version of the EPP fee extension draft. Feedback is welcome. Changes in this version: 1. Added the "applied" attribute to to elements. 2. Simplified the wording in relation to when a server can return an error for extended commands. 3. Added the element to transfer query responses. 4. Removed wording about how servers behave when receiving incorrect fee information from transform commands, and put it into a single section at the top of the document. 5. Allow servers to omit elements from elements if the command specified by the client is forbidden. Many thanks to those who gave feedback on the previous version. The long-term roadmap has two items suggested by Jim Gould: * make the extension object-agnostic so it can be used for billable transactions against any object, not just standard domain names * use a special form that's similar to the Claims Check form in draft-ietf-eppext-launchphase, so availability check results are excluded when doing a fee check (and vice versa). Regards, -------- Original Message -------- Subject: New Version Notification for draft-brown-epp-fees-03.txt Date: Mon, 29 Sep 2014 06:52:20 -0700 From: internet-drafts@ietf.org To: Gavin Brown , Gavin Brown A new version of I-D, draft-brown-epp-fees-03.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-brown-epp-fees Revision: 03 Title: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Document date: 2014-09-29 Group: Individual Submission Pages: 34 URL: http://www.ietf.org/internet-drafts/draft-brown-epp-fees-03.txt Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-0= 3 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for registry fees. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. --F8xT4Wf94k7QhaKJwvxELUJg4TCj9k81s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlQphMMACgkQ6H45IPkjtM5zmgCePiCvaxT+WSZHMDUxLZi5pwnw sCwAniSR9CLWtkf+CfkTDY/suF6vaAPG =nOU7 -----END PGP SIGNATURE----- --F8xT4Wf94k7QhaKJwvxELUJg4TCj9k81s-- From nobody Tue Sep 30 00:08:20 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA571A028B; Tue, 30 Sep 2014 00:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nDAN0M964Em; Tue, 30 Sep 2014 00:08:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AAC1A0258; Tue, 30 Sep 2014 00:08:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930070812.5864.46490.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 00:08:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/zWzpX5nJW7UKsKeik5oNiSP0U6c Cc: iesg-secretary@ietf.org Subject: [eppext] Last Call Expired: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 07:08:15 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Tue Sep 30 08:19:14 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868B71A1A33 for ; Tue, 30 Sep 2014 08:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkgdYNmuGWyk for ; Tue, 30 Sep 2014 08:19:08 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203E41A1A15 for ; Tue, 30 Sep 2014 08:19:06 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKVCrJ6Z6TX+vpiGhC+rs8YSsLLRSTaBW7@postini.com; Tue, 30 Sep 2014 08:19:07 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s8UFJ4Xn024931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 11:19:05 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 30 Sep 2014 11:19:04 -0400 From: "Gould, James" To: Gavin Brown Thread-Topic: [eppext] New Version Notification for draft-brown-epp-fees-03.txt Thread-Index: AQHP3MHeeHMV42wb7kei1sx54Sa55w== Date: Tue, 30 Sep 2014 15:19:04 +0000 Message-ID: <6F52E7C1-A6ED-43D3-AE3A-61C971DD6AE4@verisign.com> References: <20140929135220.7395.85844.idtracker@ietfa.amsl.com> <542984C2.6030102@centralnic.com> In-Reply-To: <542984C2.6030102@centralnic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_6F52E7C1A6ED43D3AE3A61C971DD6AE4verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/z6nqbvWGRtUkL3q1-JS86ev9s9c Cc: "eppext@ietf.org" Subject: Re: [eppext] New Version Notification for draft-brown-epp-fees-03.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:19:11 -0000 --_004_6F52E7C1A6ED43D3AE3A61C971DD6AE4verisigncom_ Content-Type: multipart/alternative; boundary="_000_6F52E7C1A6ED43D3AE3A61C971DD6AE4verisigncom_" --_000_6F52E7C1A6ED43D3AE3A61C971DD6AE4verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gavin, Thanks for moving this draft along. I provide rationale for the roadmap it= ems that you attributed to me below. One other item discussed privately th= at I would like to bring up publicly is the addition of an enumerated =93ty= pe=94 attribute for the element that even the elemen= t specifies the type of fee or credit without having to rely on an out-of-b= and mechanism to map the =93description=94 attribute to something meaningfu= l to the client. The text could state that the value is always a= sum of any unit based fee. Possible values for the =93type=94 a= ttribute could include values like: * =93fixed=94 - A fixed fee charged independent of the period. * =93unit=94 - Total unit fee charged based on the period. * =93tax=94 - Tax charged * =93custom=94 - Support for a custom fee, where the =93description=94 = or another attribute like =93name=94 could be used to specify the custom fe= e type. * =93total=94 - Total fee based by applying all of the fees and credits= . This could be the default =93type=94 value. =97 JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Sep 29, 2014, at 12:11 PM, Gavin Brown > wrote: Hi all, I've just published a new version of the EPP fee extension draft. Feedback is welcome. Changes in this version: 1. Added the "applied" attribute to to elements. 2. Simplified the wording in relation to when a server can return an error for extended commands. 3. Added the element to transfer query responses. 4. Removed wording about how servers behave when receiving incorrect fee information from transform commands, and put it into a single section at the top of the document. 5. Allow servers to omit elements from elements if the command specified by the client is forbidden. Many thanks to those who gave feedback on the previous version. The long-term roadmap has two items suggested by Jim Gould: * make the extension object-agnostic so it can be used for billable transactions against any object, not just standard domain names New billable objects can and have been defined using EPP, where de-coupling= the fees extension from the single domain name object, will make it more g= eneric and applicable to existing and future EPP objects. For example in .= NAME, there is the definition of three additional billable EPP objects with= Defensive Registration, Email Forwarding, and NameWatch. The fees extensi= on could be made object agnostic with some text changes and some minor sche= ma changes. For example, it is pretty straight forward to change the element to the element in the extension to the domain = check command, where all billable objects / entities would need to support = a name attribute along with the other fees attributes. In the case of .NAM= E the three objects of Defensive Registration, Email Forwarding, and NameWa= tch all support a name attribute, so they could be supported with the fees = extension. This way there would be no need to define yet another fees / pr= ice extension to support other EPP billable objects or ignore the reference= to =93domain=94 in the element for non-domain objects. * use a special form that's similar to the Claims Check form in draft-ietf-eppext-launchphase, so availability check results are excluded when doing a fee check (and vice versa). I actually question the applicability of extending the check command at all= for the fee extension, since I view the fee information as the responsibil= ity of the info command / response and not the check command. I believe t= hat the check command should be used to answer a boolean question like "is = the domain available?" or "is there a mark associated with the domain name?= =94 or =93is the fee correct?". In this case, the boolean question of whet= her a domain name is available is being mixed with a non-boolean question l= isting the fee information based on a list of domain names, each with the c= ommand, and optionally the period and currency. If the fee check was chang= ed into an actual boolean question like checking if the passed fee informat= ion is correct ahead of the future execution of a billable transform comman= d (create, renew, transfer, restore), then I would view it as a different v= erb that would be handled in a similar fashion to the claims check command = of draft-ietf-eppext-launchphase. For example, I would make the fee check = command to be an extension of a check command (domain or any object) that a= dds a single set of fee check properties that are applied to each of the ob= jects to validate by the server and return whether the fee passed is valid = in the response and if not optionally return the correct fee information. = In this case the fee check command is used to answer the boolean question o= f whether the fee of 5.00 USD passed by the client is correct for a create = of one year, during sunrise. The info command and response extension can b= e used to get the fee information ahead of time if not already known. C: C: C: C: C: C: example.com C: example.net C: example.org C: C: C: C: C: USD C: create C: 1 S: 5.00 C: C: C: ABC-12345 C: = C: S: S: S: S: S: Command completed successfully S: S: S: S: S: example.com S: S: S: example.net S: USD S: 10.00 S: S: S: example.org S: USD S: 2.50 S: 7.00 S: 9.50 S: S: S: example.xyz = S: USD S: 15.00 S: premium-tier1 S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: Regards, -------- Original Message -------- Subject: New Version Notification for draft-brown-epp-fees-03.txt Date: Mon, 29 Sep 2014 06:52:20 -0700 From: internet-drafts@ietf.org To: Gavin Brown >, Gavin Brown > A new version of I-D, draft-brown-epp-fees-03.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-brown-epp-fees Revision: 03 Title: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Document date: 2014-09-29 Group: Individual Submission Pages: 34 URL: http://www.ietf.org/internet-drafts/draft-brown-epp-fees-03.txt Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-03 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for registry fees. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_6F52E7C1A6ED43D3AE3A61C971DD6AE4verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Gavin,

Thanks for moving this draft along.  I provide rationale for the = roadmap items that you attributed to me below.  One other item discuss= ed privately that I would like to bring up publicly is the addition of an e= numerated =93type=94 attribute for the <fee:fee> element that even the <fee:credit> element specifies the type of fee= or credit without having to rely on an out-of-band mechanism to map the = =93description=94 attribute to something meaningful to the client.  Th= e text could state that the <fee:fee> value is always a sum of any unit based fee.  Possible values for the <fee:fee>= =93type=94 attribute could include values like:

  • =93fixed=94 - A fixed fee charged independent of the period.
  • = =93unit=94 - Total unit fee charged based on the period.
  • =93tax=94 = - Tax charged 
  • =93custom=94 - Support for a custom fee, where = the =93description=94 or another attribute like =93name=94 could be used to= specify the custom fee type.  
  • =93total=94 - Total fee based = by applying all of the fees and credits.  This could be the default = =93type=94 value.  



=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Principal Software Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Sep 29, 2014, at 12:11 PM, Gavin Brown <gavin.brown@centralnic.com> wrote:

Hi all,

I've just published a new version of the EPP fee extension draft.
Feedback is welcome.

Changes in this version:

  1.  Added the "applied" attribute to to <fee:= fee> elements.

  2.  Simplified the wording in relation to when a server ca= n return an
      error for extended <info> command= s.

  3.  Added the <fee:period> element to transfer query= responses.

  4.  Removed wording about how servers behave when receivin= g incorrect
      fee information from transform commands= , and put it into a single
      section at the top of the document.

  5.  Allow servers to omit <fee:fee> elements from &l= t;fee:cd> elements
      if the command specified by the client = is forbidden.

Many thanks to those who gave feedback on the previous version.

The long-term roadmap has two items suggested by Jim Gould:

* make the extension object-agnostic so it can be used for billable
transactions against any object, not just standard domain names


New billable objects can and have been defined using EPP, where de-cou= pling the fees extension from the single domain name object, will make it m= ore generic and applicable to existing and future EPP objects.  For ex= ample in .NAME, there is the definition of three additional billable EPP objects with Defensive Registration, Emai= l Forwarding, and NameWatch.  The fees extension could be made object = agnostic with some text changes and some minor schema changes.  For ex= ample, it is pretty straight forward to change the <fee:domain> element to the <fee:entity> element in the ex= tension to the domain check command, where all billable objects / entities = would need to support a name attribute along with the other fees attributes= .  In the case of .NAME the three objects of Defensive Registration, Email Forwarding, and NameWatch all support a name= attribute, so they could be supported with the fees extension.  This = way there would be no need to define yet another fees / price extension to = support other EPP billable objects or ignore the reference to =93domain=94 in the <fee:domain> element for= non-domain objects.


* use a special <check> form that's similar= to the Claims Check form in
draft-ietf-eppext-launchphase, so availability check results are
excluded when doing a fee check (and vice versa).


I actually question the applicability of extending the check command a= t all for the fee extension, since I view the fee information as the respon= sibility of the info command / response and not the check command.   I= believe that the check command should be used to answer a boolean question like "is the domain available?&q= uot; or "is there a mark associated with the domain name?=94 or =93is = the fee correct?".  In this case, the boolean question of whether= a domain name is available is being mixed with a non-boolean question listing the fee information based on a list of domain names, each= with the command, and optionally the period and currency.  If the fee= check was changed into an actual boolean question like checking if the pas= sed fee information is correct ahead of the future execution of a billable transform command (create, renew, tr= ansfer, restore), then I would view it as a different verb that would be ha= ndled in a similar fashion to the claims check command of draft-ietf-eppext= -launchphase.  For example, I would make the fee check command to be an extension of a check command (domain o= r any object) that adds a single set of fee check properties that are appli= ed to each of the objects to validate by the server and return whether the = fee passed is valid in the response and if not optionally return the correct fee information.  In this ca= se the fee check command is used to answer the boolean question of whether = the fee of 5.00 USD passed by the client is correct for a create of one yea= r, during sunrise.  The info command and response extension can be used to get the fee information ahead of tim= e if not already known.  

   C: <?xml version=3D"1.0&qu=
ot; encoding=3D"utf-8" standalone=3D"no"?>
   C: <epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
   C:   <command>
   C:     <check>
   C:       <domain:check
   C:         xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0"&=
gt;
   C:         <domain:name>example.com=
</domain:name>
   C:         <domain:name>example.net=
</domain:name>
   C:         <domain:name>example.org=
</domain:name>
   C:       </domain:check>
   C:     </check>
   C:     <extension>
   C:       <fee:check
   C:         xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.6">
   C:         <fee:currency>USD</fee:currency>
   C:         <fee:command phase=3D"sunrise">create</fee=
:command>
   C:         <fee:period unit=3D"y">1</fee:period>

   S:         <fee:fee>5.00<=
/fee:fee>

   C:       </fee:check>
   C:     </extension>
   C:     <clTRID>ABC-12345</clTRID>
   C:   </command>
   C: </epp>




   S: <?xml version=3D"1.0&qu=
ot; encoding=3D"utf-8" standalone=3D"no"?>
   S: <epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
   S:   <response>
   S:     <result code=3D"1000">
   S:       <msg>Command completed successfully</msg>
   S:     </result>
   S:=
     <extension>

   S:       <fee:chkData
   S:         xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.6">
   S:         <fee:cd>
   S:           <fee:name valid=3D=931">example.com</fee:name>
   S:         </fee:cd>
   S:         <fee:cd>
   S:           <fee:name valid=3D=930">example.net</fee:name>
   S:           <fee:currency>USD</fee:currency>
   S:           <fee:fee>10.00</fee:fee>
   S:         </fee:cd>
   S:         <fee:cd>
   S:           <fee:name valid=3D=930">example.org</fee:name>
   S:           <fee:currency>USD</fee:currency>
   S:           <fee:fee description=3D=93Fixed Fee">2.50</fe=
e:fee>
   S:           <fee:fee description=3D=93Annual Fee=94>7.00</fee:=
fee>

   S:           <fee:fee>9.50&l=
t;/fee:fee>

   S:         </fee:cd>
   S:         <fee:cd>
   S:           <fee:name valid=3D=930">example.xyz</fee:name=
>
   S:           <fee:currency>USD</fee:currency>

   S:           <fee:fee>15.00&=
lt;/fee:fee>

   S:           <fee:class>premium-tier1</fee:class>
   S:         </fee:cd>
   S:=
       </fee:chkData>

   S:     </extension>
   S:     <trID>
   S:       <clTRID>ABC-12345</clTRID>
   S:       <svTRID>54322-XYZ</svTRID>
   S:     </trID>
   S:   </response>
   S: </epp>



Regards,

-------- Original Message --------
Subject: New Version Notification for draft-brown-epp-fees-03.txt
Date: Mon, 29 Sep 2014 06:52:20 -0700
From: internet-drafts@ietf.org<= /a>
To: Gavin Brown <gavin.bro= wn@centralnic.com>, Gavin Brown
<gavin.brown@centralnic.co= m>


A new version of I-D, draft-brown-epp-fees-03.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name: draft-brown-epp-= fees
Revision: 0= 3
Title: Registry Fee Ex= tension for the Extensible Provisioning Protocol
(EPP)
Document date: 2014-09-29
Group: Individual Subm= ission
Pages: 34
URL:
http://www.ietf.org/internet-drafts/draft-brown-epp-fees-03.txt
Status:         https://datatracker.ietf.or= g/doc/draft-brown-epp-fees/
Htmlized:       http://tools.ietf.org/html/draft-brown-ep= p-fees-03
Diff:           http://www.= ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-03

Abstract:
  This document describes an Extensible Provisioning Protocol (EP= P)
  extension mapping for registry fees.





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

The IETF Secretariat


--
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/eppext

--_000_6F52E7C1A6ED43D3AE3A61C971DD6AE4verisigncom_-- --_004_6F52E7C1A6ED43D3AE3A61C971DD6AE4verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 30 Sep 2014 15:19:04 GMT"; modification-date="Tue, 30 Sep 2014 15:19:04 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_6F52E7C1A6ED43D3AE3A61C971DD6AE4verisigncom_-- From nobody Tue Sep 30 08:58:52 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5541A1AA3; Tue, 30 Sep 2014 08:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXY7Cr-Moq_D; Tue, 30 Sep 2014 08:58:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 183BD1A1A7B; Tue, 30 Sep 2014 08:58:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930155846.26499.63399.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 08:58:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/XQtuSD0el7I0oE38thQl7467vgI Cc: draft-ietf-eppext-reg@tools.ietf.org, eppext-chairs@tools.ietf.org, eppext@ietf.org Subject: [eppext] Brian Haberman's No Objection on draft-ietf-eppext-reg-08: (with COMMENT) X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:58:49 -0000 Brian Haberman has entered the following ballot position for draft-ietf-eppext-reg-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Does the WG want to put any limitations on the Reference portion of the registry entry? I was wondering how useful the Reference field would be if the link was: 1) behind a paywall, 2) restricted to "members", or 3) not publicly available. From nobody Tue Sep 30 14:06:11 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964EC1A9124 for ; Tue, 30 Sep 2014 14:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JjvHzpwKLCG; Tue, 30 Sep 2014 14:06:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 923911A90E8; Tue, 30 Sep 2014 14:06:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930210608.22294.47849.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 14:06:08 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/wq5sGNkLP-qvaSqdI0n_WmBhToQ Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:06:09 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Tue Sep 30 15:14:54 2014 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D051ACC8A for ; Tue, 30 Sep 2014 15:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-Xqzs04f0fa; Tue, 30 Sep 2014 15:14:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5C1ACC81; Tue, 30 Sep 2014 15:14:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930221450.18166.66076.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 15:14:50 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/a7aCeLVlHbx_1LBJR9O843-QTZU Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 22:14:52 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/