Return-Path: X-Original-To: regext@ietfa.amsl.com Delivered-To: regext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB447C1CAF4A for ; Mon, 22 Jul 2024 10:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=elistx-com.20230601.gappssmtp.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abEpI4jkmkhx for ; Mon, 22 Jul 2024 10:21:25 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76145C1D4A90 for ; Mon, 22 Jul 2024 10:21:25 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-2cd2f89825fso1063631a91.1 for ; Mon, 22 Jul 2024 10:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elistx-com.20230601.gappssmtp.com; s=20230601; t=1721668885; x=1722273685; darn=ietf.org; h=embedded-html:mime-version:references:in-reply-to:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=rEvLuIP0s4xCAIXPpatfLdd98CikpWWeaEQcWh04uqo=; b=LRMYYTUi9GWFjZYxQ1wa/jQgveJ7fZtPsWg8TRgbHYX536qA12yW5jgQBdvcKiNhhB aOuSB8TbOCIppOjrvmTrX3pkR08KbNsRa+SMdfvk97UIN0L7am+PlIZILjUm09WGGyxF nQA+cusDY4gomvYnJSvbb8+g6a8cDdSlmZDig46gdQUII1OdddRbW7f2PXiKVMYUTCcB crh4rGKF5gpMBDQd7/Sf/0OoAZpYgXFht0fn0aVqqsRXGa9fLQhaU/40SJDhdB9ZlEVm YsKzxeHpwKK1nam74gDL0FVyYIyjDPOwQl1BgHARFh+NBDdTAqpWmpmxuwQ0WMeMEmGo wTVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721668885; x=1722273685; h=embedded-html:mime-version:references:in-reply-to:message-id:date :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rEvLuIP0s4xCAIXPpatfLdd98CikpWWeaEQcWh04uqo=; b=qhiS+R9pXvs8kqX0irC3GvcSK3d7ksZ9CGO7dCSLaeALi2O/FFzQLZ01NFCWG+cmTY 8xCve95BePW9zLaP0r1sSA/+s0PLPTdfRWbWlpfwrHQcgEjapkPcRgHIlit5ee4gQkGR aPu8BLLxOMDnFJKDRE/a+LCUZxxaLLcnqbwEg4Z6IfWldQTwT87uG6yDeh77DES38SPY GzPOs7TKwTtmBV5CbmGR0IU0DP87Uu6cNmlI5htzYBuE7rs07bHKeRn0uW9zlPNcJzgx 8l9NUIi/waIDkhNUtIoEYeMUEoQUfL83Hd/VP9t2BNob/LnrwS1DIC1JirGq8aVJEBL9 iHgg== X-Gm-Message-State: AOJu0YxCNxYpCW2Nis+y3Q6vaCx4K9dM/ZPb15js1qmlJ7JzdQvAq2Fr muZ/X+dRj1Sw61Uh+dDX5AC9D5oirEVbMshsL/0AT8o9XlpDZBDuOw5rr3SlJ/VXbfycnrwiscY L7fCP5g== X-Google-Smtp-Source: AGHT+IH0X9cDPyVHZYlKh8i3VynQ0AYUYIuyuUhwRmgg8DGla/4CmRjP1jT6NAc16kNrOvXfwS1MBg== X-Received: by 2002:a17:90a:ea81:b0:2c4:dcf6:2130 with SMTP id 98e67ed59e1d1-2cd161b02c4mr4736609a91.32.1721668884485; Mon, 22 Jul 2024 10:21:24 -0700 (PDT) Received: from [172.20.0.193] ([173.214.130.139]) by smtp.googlemail.com with ESMTPSA id 98e67ed59e1d1-2ccf7b2d5e2sm7263063a91.7.2024.07.22.10.21.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2024 10:21:23 -0700 (PDT) From: James Galvin To: "Gould, James" Date: Mon, 22 Jul 2024 10:21:23 -0700 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: <3F7C7147-048B-4E8E-85DE-C5C886F08140@verisign.com> References: <3F7C7147-048B-4E8E-85DE-C5C886F08140@verisign.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E9283E85-3781-46F9-9B4B-E3FEDAE697E1_=" Embedded-HTML: [{"plain":[629,8375],"uuid":"7CC6BE1E-A5C0-406F-8312-B8E2C5FEB061"}] Message-ID-Hash: X4U3BVKDID3PYJKS2PGBNAFS3PO6U3G6 X-Message-ID-Hash: X4U3BVKDID3PYJKS2PGBNAFS3PO6U3G6 X-MailFrom: galvin@elistx.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: regext@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bregext=5D_Re=3A_Review_of_draft-ietf-regext-rdap-versioning=2C_?= =?utf-8?q?draft-ietf-regext-rdap-x-media-type=2C_and_draft-ietf-regext-rdap?= =?utf-8?q?-extensions?= List-Id: Registration Protocols Extensions Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=_MailMate_E9283E85-3781-46F9-9B4B-E3FEDAE697E1_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Speaking as co-Chair: Thank you Jim for these detailed comments. For the working group, the question that will be before us in the = discussion on Wednesday, which was also before us at IETF119, is what = problem are we trying to solve? The second order question, which was = also before us at IETF119, is what is the relationship between these = documents. Jim=E2=80=99s note is a pretty deep consideration of that sec= ond = question. Please come prepared on Wednesday to discuss the first question. There = will be Chair slides later today with more details. Thanks, Jim co-Chair REGEXT On 22 Jul 2024, at 7:59, Gould, James wrote: > Hi, > > I did a detailed review of the three drafts = > draft-ietf-regext-rdap-versioning, = > draft-ietf-regext-rdap-x-media-type, and = > draft-ietf-regext-rdap-extensions for alignment. The following are my = > findings: > > > 1. draft-ietf-regext-rdap-versioning includes support for = > draft-ietf-regext-rdap-x-media-type and the =E2=80=9Cversioning=E2=80=9D= query = > parameter for the client to provide a hint of the extension versions = > to include in the RDAP query and RDAP response. The server MUST = > support both methods and the client MUST include a single method in = > the RDAP query to ensure that there are no conflicts. This ensures = > that clients can specify the extension versions via a query parameter = > and via an HTTP header per draft-ietf-regext-rdap-x-media-type. > 2. draft-ietf-regext-rdap-x-media-type could be merged into = > draft-ietf-regext-rdap-versioning, since it now represents one method = > of an Extension Versioning Request. > * An alternative is for draft-ietf-regext-rdap-x-media-type to = > support a more generic form of query parameters for use in any RDAP = > extension. > * The extension can stay separate if there is some advantage. > 3. draft-ietf-regext-rdap-versioning defines a Extension Version = > Identifier in section 3.1 = > https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-versioning= #name-extension-version-identifie = > as: > * ABNF > > i. = > extension-version-identifier =3D identifier versioning > > ii. = > identifier =3D ALPHA *( ALPHA / DIGIT / "_") ; Extension Identifer > > iii. = > versioning =3D ["-" 1*VCHAR] > > * draft-ietf-regext-rdap-x-media-type needs to also support the = > extension-version-identifier to use it with = > draft-ietf-regext-rdap-versioning, which currently uses the language: > > i. = > =E2=80=9CThis media type has a parameter of "extensions" which is a = > whitespace-separated list of RDAP extensions as defined in the IANA = > RDAP Extensions registry.=E2=80=9D > > * How about making this more generic to support = > additional types of extension versioning schemes, such as the = > language: > * =E2=80=9CThis media type has a parameter of "extensio= ns" = > which is a whitespace-separated list of RDAP extensions, such as = > defined in the IANA RDAP Extensions registry.=E2=80=9D > > = i. = > Use of the IANA RDAP Extensions registry will support Opaque = > Versioning in draft-ietf-regext-rdap-versioning, where use of =E2=80=9C= such = > as=E2=80=9D will allow for additional RDAP extensions schemes. > > ii. = > =E2=80=9Cthe values in the media type's extension parameter SHOULD matc= h the = > values in the rdapConformance array in the return JSON.=E2=80=9D > > * The Extension Version Identifier does include the = > extension identifier, so the question is whether inclusion of the = > versioning suffix will meet the =E2=80=9Cmatch the values in the = > rdapConformance array=E2=80=9D. > * How about making this more specific to directly = > reference the version identifiers, which would work better with = > draft-ietf-regext-rdap-versioning: > * =E2=80=9Cthe extension identifier values in the media= = > type's extension parameter SHOULD match the values in the = > rdapConformance array in the return JSON.=E2=80=9D > * =E2=80=9Cthough clients SHOULD list the extension identi= fier = > in the extensions parameter when using other protocol elements of = > those extensions. Servers SHOULD NOT require the usage of extension = > identifiers in the extensions paramater when other extension protocol = > elements are used. > * To support draft-ietf-regext-rdap-versioning, this = > could be modified as: > > = i. = > =E2=80=9Cthough clients SHOULD list the extension identifier in th= e = > extensions parameter when using other protocol elements of those = > extensions. Servers SHOULD NOT require the usage of extensions = > identifiers in the extensions parameter when other extension protocol = > elements are used=E2=80=9D > > = ii. = > Referencing extension instead of extension identifier would be = > more generic to support the Extension Version Identifier. > > = iii. = > Nit =E2=80=93 replace =E2=80=9Cparamater=E2=80=9D with =E2=80=9Cpa= rameter=E2=80=9D > > 1. draft-ietf-regext-rdap-x-media-type Security Considerations = > parameter below may be best to address in = > draft-ietf-regext-rdap-versioning and even more generically in = > draft-ietf-regext-rdap-extensions > * =E2=80=9CThis specification does contrast with solutions using= = > query parameters in that those solutions require servers to blindly = > copy query parameters into redirect URLs in situations where such = > copying could cause harm, such as copying an API key intended for one = > server into the redirect URL of another server.=E2=80=9D > 2. draft-ietf-regext-rdap-x-media-type B.2 =E2=80=9CQuery Parameters= = > Considered Harmful=E2=80=9D could be moved to = > draft-ietf-regext-rdap-extensions, since query parameters are used in = > many places in RDAP, so providing clear guidance when a query = > parameter should or should not be used would be useful in = > draft-ietf-regext-rdap-extensions. I don=E2=80=99t believe query param= eters = > are =E2=80=9Charmful=E2=80=9D but has a disadvantage in the use cases p= resented. = > The query parameter has the advantage of being a simple approach for = > clients to provide their hint when directly interfacing with the = > server. In re-reviewing draft-ietf-regext-rdap-extensions it does = > look like section 12 =E2=80=9CRedirects=E2=80=9D includes some guidance= related to = > query parameters, where I believe it would be beneficial to have a = > separate query parameter section in draft-ietf-regext-rdap-extensions. > 3. draft-ietf-regext-rdap-x-media-type B.2.4 =E2=80=9CArchitectural = > Violations=E2=80=9D and B.3 =E2=80=9CRDAP Extension Versioning=E2=80=9D= could be = > removed, since I don=E2=80=99t see how the use of a query parameter in = RDAP = > would be considered an architectural violation and RDAP Extension = > Versioning will be worked on in parallel in = > draft-ietf-regext-rdap-versioning. > 4. draft-ietf-regext-rdap-versioning > * In section 8 =E2=80=9CExtension Versioning=E2=80=9D, I just wa= nt to = > confirm that draft-ietf-regext-rdap-versioning address the normative = > language and if not what needs to be added: > > i. = > =E2=80=9CIf a future RFC defines a versioning scheme (such as using the= = > mechanims defined in section Section = > 2 = > ), an RDAP extension definition MUST explicitly denote this = > compliance.=E2=80=9D > > * Section 8.1 =E2=80=9CBackwards-Compatible Changes=E2=80=9D > > i. = > This section may not be needed with draft-ietf-regext-rdap-versioning, = > since the set of supported extension versions are explicitly = > specified, where in the case of Opaque Versioning the server could = > support many versions of the extension. > > * Section 8.2 =E2=80=9CBackwards-Incompatible Changes=E2=80=9D > > i. = > IT would be helpful to include the reference to = > draft-ietf-regext-rdap-versioning as an option to consider in = > signaling support for more than one version of an extension. > > * Section 9 =E2=80=9CExtension Identifiers in a Response=E2=80=9D= > > i. = > You can update the reference of [I-D.gould-regext-rdap-versioning] to = > be [I-D.draft-ietf-regext-rdap-versioning]. > Thanks, > > -- > > JG > > [cid87442*image001.png@01D960C5.C631DA40] > > James Gould > Fellow Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > _______________________________________________ > regext mailing list -- regext@ietf.org > To unsubscribe send an email to regext-leave@ietf.org --=_MailMate_E9283E85-3781-46F9-9B4B-E3FEDAE697E1_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Speaking as co-Chair:


Thank you Jim for these detailed comments.

For the working group, the question that will be before u= s in the discussion on Wednesday, which was also before us at IETF119, is= what problem are we trying to solve? The second order question, which w= as also before us at IETF119, is what is the relationship between these d= ocuments. Jim=E2=80=99s note is a pretty deep consideration of that seco= nd question.

Please come prepared on Wednesday to discuss the first qu= estion. There will be Chair slides later today with more details.


Thanks,

Jim
co-Chair REGEXT



On 22 Jul 2024, at 7:59, Gould, James wrote:

Hi,

 

I did a detailed review of the three drafts draft-= ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and dra= ft-ietf-regext-rdap-extensions for alignment.  The following are my = findings:

 

  1. draft-ietf-regext-rdap-versioning includ= es support for draft-ietf-regext-rdap-x-media-type and the =E2=80=9Cversi= oning=E2=80=9D query parameter for the client to provide a hint of the ex= tension versions to include in the RDAP query and RDAP response.  Th= e server MUST support both methods and the client MUST include a single m= ethod in the RDAP query to ensure that there are no conflicts.  This= ensures that clients can specify the extension versions via a query para= meter and via an HTTP header per draft-ietf-regext-rdap-x-media-type.&nbs= p;
  2. draft-ietf-regext-rdap-x-media-type coul= d be merged into draft-ietf-regext-rdap-versioning, since it now represen= ts one method of an Extension Versioning Request. 
    1. An alternative is for draft-ietf-regext-= rdap-x-media-type to support a more generic form of query parameters for = use in any RDAP extension. 
    2. The extension can stay separate if there= is some advantage. 
  3. draft-ietf-regext-rdap-versioning define= s a Extension Version Identifier in section 3.1 https://datatracker.ietf.org/doc/html/draft-ietf-regex= t-rdap-versioning#name-extension-version-identifie as:
    1. ABNF

    &nb= sp;           &nbs= p;            = ;            =             &= nbsp;        i.      extension-version-identifier =3D identifier versioni= ng

<=
span style=3D"font:7.0pt "Times New Roman"">                   =
                                          ii.      =
identifier =3D ALPHA *( ALPHA / DIGIT / "_") ; Extension Identifer
<=
span style=3D"font:7.0pt "Times New Roman"">                   =
                                        iii.      ve=
rsioning =3D ["-" 1*VCHAR]
    1. draft-ietf-regext-rdap-x-media-type need= s to also support the extension-version-identifier to use it with draft-i= etf-regext-rdap-versioning, which currently uses the language:

    &nb= sp;           &nbs= p;            = ;            =             &= nbsp;        i.      =E2=80=9CThis media type has a parameter of "extensi= ons" which is a whitespace-separated list of RDAP extensions as defined i= n the IANA RDAP Extensions registry.=E2=80=9D

        1. How about making this more generic to su= pport additional types of extension versioning schemes, such as the langu= age:
          1. =E2=80=9CThis media type has a parameter= of "extensions" which is a whitespace-separated list of RDAP extensions,= such as defined in the IANA RDAP Extensions registry.=E2=80=9D

    &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;       i.      Use of the IANA RDAP Extensions registry will support Opaq= ue Versioning in draft-ietf-regext-rdap-versioning, where use of =E2=80=9C= such as=E2=80=9D will allow for additional RDAP extensions schemes.

    &nb= sp;           &nbs= p;            = ;            =             &= nbsp;       ii.     = =E2=80=9Cthe values in the media type's extension param= eter SHOULD match the values in the rdapConformance array in th= e return JSON.=E2=80=9D

        1. The Extension Version Identifier does in= clude the extension identifier, so the question is whether inclusion of t= he versioning suffix will meet the =E2=80=9Cmatch the values in the rdapC= onformance array=E2=80=9D. 
        2. How about making this more specific to d= irectly reference the version identifiers, which would work better with d= raft-ietf-regext-rdap-versioning:
          1. =E2=80=9Cthe extension identifier values= in the media type's extension parameter SHOULD match the values in the&n= bsp;rdapConformance array in the return JSON.=E2=80=9D
        3. =E2=80=9Cthough clients SHOULD list the = extension identifier in the extensions parameter when using other protoco= l elements of those extensions.  Servers SHOULD NOT require the usag= e of extension identifiers in the extensions paramater when other extensi= on protocol elements are used.
          1. To support draft-ietf-regext-rdap-versio= ning, this could be modified as:

    &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;       i.      =E2=80=9Cthough clients SHOULD list the extension identifier in the extensions parameter wh= en using other protocol elements of those extensions.  Servers SHOUL= D NOT require the usage of extensions identi= fiers in the extensions parameter when other extension = protocol elements are used=E2=80=9D

    &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;      ii.      = Referencing extension instead of extension identifier would be = more generic to support the Extension Version Identifier.

    &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;    iii.      N= it =E2=80=93 replace =E2=80=9Cparamater=E2=80=9D with =E2=80=9Cparameter=E2= =80=9D

  1. draft-ietf-regext-rdap-x-media-type Secu= rity Considerations parameter below may be best to address in draft-ietf-= regext-rdap-versioning and even more generically in draft-ietf-regext-rda= p-extensions
    1. =E2= =80=9CThis specification does contrast with solutions using query paramet= ers in that those solutions require servers to blindly copy query paramet= ers into redirect URLs in situations where such copying could cause harm,= such as copying an API key intended for one server into the redirect URL= of another server.=E2=80=9D
  2. draft-ietf-regext-rdap-x-media-type B.2 = =E2=80=9CQuery Parameters Considered Harmful=E2=80=9D could be moved to d= raft-ietf-regext-rdap-extensions, since query parameters are used in many= places in RDAP, so providing clear guidance when a query parameter shoul= d or should not be used would be useful in draft-ietf-regext-rdap-extensi= ons.  I don=E2=80=99t believe query parameters are =E2=80=9Charmful=E2= =80=9D but has a disadvantage in the use cases presented.  The query= parameter has the advantage of being a simple approach for clients to pr= ovide their hint when directly interfacing with the server.  In re-r= eviewing draft-ietf-regext-rdap-extensions it does look like section 12 =E2= =80=9CRedirects=E2=80=9D includes some guidance related to query paramete= rs, where I believe it would be beneficial to have a separate query param= eter section in draft-ietf-regext-rdap-extensions.   
  3. draft-ietf-regext-rdap-x-media-type B.2.= 4 =E2=80=9CArchitectural Violations=E2=80=9D and B.3 =E2=80=9CRDAP Extens= ion Versioning=E2=80=9D could be removed, since I don=E2=80=99t see how t= he use of a query parameter in RDAP would be considered an architectural = violation and RDAP Extension Versioning will be worked on in parallel in = draft-ietf-regext-rdap-versioning. 
  4. draft-ietf-regext-rdap-versioning
    1. In section 8 =E2=80=9CExtension Versioni= ng=E2=80=9D, I just want to confirm that draft-ietf-regext-rdap-versionin= g address the normative language and if not what needs to be added:

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;     i.      =E2=80=9CIf a future RFC defines a versioning scheme (such as using th= e mechanims defined in section Section 2), a= n RDAP extension definition MUST explicitly denote this compliance.=E2=80= =9D

    1. Section 8.1 =E2=80=9CBackwards-Compatible Changes=E2=80=9D=

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;     i.      This section may not be needed with draft-ietf-regext-rdap-versioning,= since the set of supported extension versions are explicitly specified, = where in the case of Opaque Versioning the server could support many vers= ions of the extension.

    1. Section 8.2 =E2=80=9CBackwards-Incompatible Changes=E2=80=9D=

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;     i.      IT would be helpful to include the reference to draft-ietf-regext-rdap= -versioning as an option to consider in signaling support for more than o= ne version of an extension. 

    1. Section 9 =E2=80=9CExtension Identifiers in a Response=E2=80= =9D

       &nb= sp;           &nbs= p;            = ;            =             &= nbsp;     i.      You can update the reference of [I-D.gould-regext-rdap-versioning] to = be [I-D.draft-ietf-regext-rdap-versioning].

Thanks,

 

-- 

 

JG


3D"cid87442*image001.png@01D960C5.C631DA40"

 James Gould
 Fellow Engineer
jgould@Verisign.com

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

Verisign.com

________________________= _______________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-leave@ietf.org

--=_MailMate_E9283E85-3781-46F9-9B4B-E3FEDAE697E1_=--