Re: [regext] New Version Notification for draft-regext-brown-epp-ttl-01.txt

["Gould, James" <[e-mail]>]

Tim,

Yes, what is meant as host-level is using the TTL extension for host objects in RFC 5732, as opposed to using the TTL extension domain name objects in RFC 5731.  There is one TTL attribute set at the domain-level or at the host-level, so the question is what resource records that attribute applies to in DNS.  The initial versions of the draft, draft-regext-brown-epp-ttl-00 and draft-regext-brown-epp-ttl-01, had the single domain-level TTL apply to all the domain-level resource records (NS, DS) as well as the host-level resources records (A, AAAA).  By extending the host object in RFC 5732, the A and AAAA can be set to the single TTL value for all glue independent from the domain-level resource records (NS, DS, DNAME) in draft-regext-brown-epp-ttl-02.

--

JG

[cid:image001.png@01D8D255.6B983560]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]> on behalf of Tim Wicinski <[e-mail]>
Date: Tuesday, September 27, 2022 at 9:22 AM
To: "Gould, James" <jgould=[e-mail]>
Cc: Gavin Brown <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] New Version Notification for draft-regext-brown-epp-ttl-01.txt



On Tue, Sep 27, 2022 at 9:17 AM Gould, James <jgould=[e-mail]<mailto:[e-mail]>> wrote:
Gavin,

I believe the domain-level TTL applies to the records it owns, which include the DS, NS, and DNAME.  The host-level TTL applies to the records it owns, which include the A and AAAA.  In your examples, if we're talking about the NS TTL of the example.com<http://secure-web.cisco.com/11iTMEWrL_zQUJgLHR2YrPiSgAt-ABL-D5ojittXqlASHBTgCrFLbAi9lZqkoFgS6BU46hPpSDNt42TY5efa_vDTVp1xdvu6cy92BW5Nx6jkjeJ8cXHPglssqhfWRJOBLJXjbkeKRiVclouxoW3L87iQu6xGiqzt9dNoO5YyWlNHs6NM4KFvvz0DPuK17VTd_qyLCqUoNqUfyuUdxzkgHBgGmj0hwzbTwy-P8oVN4R8c0nnUAZ_8OX5OMEEZB58Uc/http%3A%2F%2Fexample.com> delegating name server ns1.example.com<http://secure-web.cisco.com/1OUI3m-nD25pKOP8NaFtlTae5rrbrN60X5LZVHGpwo_sR1NGle3a7As323IrCeVNyRS_QH5bMPduXCfTidlz-gSAOioCUZOxmqU4RPaAIBjZAETr8Ic4im0YQ029fnTZgOEvkMeGr7w-5LPelPeBNJwlwEvsExV8uIyLxofCAXvp8tVpkjFoAwMCye9X2YpTmMT6ogyGYJE1edu36qMtXIxEL0j3ooGyUMzkD_LdM3q1sHG3YV6zMVS_Xo5_Mw2Td/http%3A%2F%2Fns1.example.com>, it would be 3600 for both.  If the ns1.example.com<http://secure-web.cisco.com/1OUI3m-nD25pKOP8NaFtlTae5rrbrN60X5LZVHGpwo_sR1NGle3a7As323IrCeVNyRS_QH5bMPduXCfTidlz-gSAOioCUZOxmqU4RPaAIBjZAETr8Ic4im0YQ029fnTZgOEvkMeGr7w-5LPelPeBNJwlwEvsExV8uIyLxofCAXvp8tVpkjFoAwMCye9X2YpTmMT6ogyGYJE1edu36qMtXIxEL0j3ooGyUMzkD_LdM3q1sHG3YV6zMVS_Xo5_Mw2Td/http%3A%2F%2Fns1.example.com> host TTL was set to 86400, it would be applied to the A and AAAA glue records.

--

Each RRSet can have its own TTL different from other RRSets with the same name (ie, the TTL for A records can be different for AAAA records).

Are you referring to the host-level TTL which is at the Registry level ?  You could define those to be the same.

tim




JG



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

Verisign.com <http://verisigninc.com/<http://secure-web.cisco.com/1ekA_JkSK-51ZTOk-qt9xAadB49ud5mzyoI8ewQzoQJBkAjeuyT7LnEN8DVtDhTvfDyFaKESE9QmKXZj3Ytvouzb-L3mkLrdAcABEpv56oHGYUzJH5hZGLu8XZ4GB4Ni5AKxsAGzOTKvKwft_kbYJ0eWcALdzAj5L0bUvNke2HuSbZOr5niNhlrGM5OL427ErUOIA_mrlv6Ilb0ZLV3WeXNUNubMDXMQqYy1OTGJ_OH2Qdo0oxvDBQ7KQeYYyoCcO/http%3A%2F%2Fverisigninc.com%2F>>

On 9/27/22, 6:48 AM, "Gavin Brown" <[e-mail]<mailto:[e-mail]>> wrote:

    Thanks Rick and Jim for the feedback. I am happy to accept the idea of the extension working for both domain and host objects and will work towards making that a part of the next version.

    One point for possible further discussion is the "priority" of TTL values: I am going to state that the TTL value of the host object takes priority over the TTL of the superordinate domain. So if:

        com default TTL: 172800
        example.com<http://secure-web.cisco.com/11iTMEWrL_zQUJgLHR2YrPiSgAt-ABL-D5ojittXqlASHBTgCrFLbAi9lZqkoFgS6BU46hPpSDNt42TY5efa_vDTVp1xdvu6cy92BW5Nx6jkjeJ8cXHPglssqhfWRJOBLJXjbkeKRiVclouxoW3L87iQu6xGiqzt9dNoO5YyWlNHs6NM4KFvvz0DPuK17VTd_qyLCqUoNqUfyuUdxzkgHBgGmj0hwzbTwy-P8oVN4R8c0nnUAZ_8OX5OMEEZB58Uc/http%3A%2F%2Fexample.com> TTL: 3600:
        ns1.example.com<http://secure-web.cisco.com/1OUI3m-nD25pKOP8NaFtlTae5rrbrN60X5LZVHGpwo_sR1NGle3a7As323IrCeVNyRS_QH5bMPduXCfTidlz-gSAOioCUZOxmqU4RPaAIBjZAETr8Ic4im0YQ029fnTZgOEvkMeGr7w-5LPelPeBNJwlwEvsExV8uIyLxofCAXvp8tVpkjFoAwMCye9X2YpTmMT6ogyGYJE1edu36qMtXIxEL0j3ooGyUMzkD_LdM3q1sHG3YV6zMVS_Xo5_Mw2Td/http%3A%2F%2Fns1.example.com> TTL: (undefined)

    then the TTL for NS records delegating to ns1.example.com<http://secure-web.cisco.com/1OUI3m-nD25pKOP8NaFtlTae5rrbrN60X5LZVHGpwo_sR1NGle3a7As323IrCeVNyRS_QH5bMPduXCfTidlz-gSAOioCUZOxmqU4RPaAIBjZAETr8Ic4im0YQ029fnTZgOEvkMeGr7w-5LPelPeBNJwlwEvsExV8uIyLxofCAXvp8tVpkjFoAwMCye9X2YpTmMT6ogyGYJE1edu36qMtXIxEL0j3ooGyUMzkD_LdM3q1sHG3YV6zMVS_Xo5_Mw2Td/http%3A%2F%2Fns1.example.com> should be 3600, but if

        com default TTL: 172800
        example.com<http://secure-web.cisco.com/11iTMEWrL_zQUJgLHR2YrPiSgAt-ABL-D5ojittXqlASHBTgCrFLbAi9lZqkoFgS6BU46hPpSDNt42TY5efa_vDTVp1xdvu6cy92BW5Nx6jkjeJ8cXHPglssqhfWRJOBLJXjbkeKRiVclouxoW3L87iQu6xGiqzt9dNoO5YyWlNHs6NM4KFvvz0DPuK17VTd_qyLCqUoNqUfyuUdxzkgHBgGmj0hwzbTwy-P8oVN4R8c0nnUAZ_8OX5OMEEZB58Uc/http%3A%2F%2Fexample.com> TTL: 3600:
        ns1.example.com<http://secure-web.cisco.com/1OUI3m-nD25pKOP8NaFtlTae5rrbrN60X5LZVHGpwo_sR1NGle3a7As323IrCeVNyRS_QH5bMPduXCfTidlz-gSAOioCUZOxmqU4RPaAIBjZAETr8Ic4im0YQ029fnTZgOEvkMeGr7w-5LPelPeBNJwlwEvsExV8uIyLxofCAXvp8tVpkjFoAwMCye9X2YpTmMT6ogyGYJE1edu36qMtXIxEL0j3ooGyUMzkD_LdM3q1sHG3YV6zMVS_Xo5_Mw2Td/http%3A%2F%2Fns1.example.com> TTL: 86400

    then the TTL should be 86400.

    G.

    > On 26 Sep 2022, at 13:41, Rick Wilhelm <[e-mail]> wrote:
    >
    > Gavin,
    >
    > Just a +1 for having this extension cover both the domain and host objects.
    >
    > The sibling glue model has enough deployment that having the extension cover both models makes sense.
    >
    >
    > One other thing… and this is not a call for a change, just concurrence to an existing design choice that is in the draft.  I like the behavior described for Server Processing of TTL Values (Section 4, paragraph 2) where the description covers the scenario where the TTL values are outside the range.
    >
    > The doc says to reject the command with a 2004 “Parameter value range error”.  I was wondering if this might be “too aggressive” for a <create> (it clearly makes sense for an <update>), but after some thought, I agree with the current behavior.
    >
    > First, it’s consistent.  Second, since the extension is optional (and since hosts links are optional on domain::create, the extension is “2x-optional”), it is better to “fast fail” due to validation enforcement.  Because to let the <domain::create> go through and have the invalid values flagged with only a warning is more likely to lead to confusion in the future.  That is, a client that is not properly respecting the limits of the TTL values is also unlikely to be heading a hypothetical warning value.
    >
    > So, bottom line, after some thought, I like the way that this works.
    >
    >
    > Thanks
    > Rick
    >
    >
    >
    >
    >
    > From: regext <[e-mail]<mailto:[e-mail]>> on behalf of Gould, James <jgould=[e-mail]<mailto:[e-mail]>>
    > Date: Monday, September 19, 2022 at 9:48 AM
    > To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]><[e-mail]<mailto:[e-mail]>>
    > Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
    > Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-01.txt
    >
    > CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.
    >
    > Gavin,
    >
    > The TTL for the A/AAAA records need to be applied to the host object and the TTL for the NS and DS records need to be applied to the domain object. Setting the A/AAAA TTL at the host object level would apply to registries that implement sibling glue as well as CentralNic and TANGO that implement in-bailiwick only glue.
    >
    > --
    >
    > JG
    >
    >
    >
    > James Gould
    > Fellow Engineer
    > [e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
    >
    > 703-948-3271
    > 12061 Bluemont Way
    > Reston, VA 20190
    >
    > Verisign.com <http://secure-web.cisco.com/1rl_OvR6_k8szzz82KnsefauK2VVokmHEilpYRTh_bVhZ8bgeo-8SaO5imViM18jSfegFFfsa2CWcLPV7Gbp2E_kjmnltoelhZ7LF9LAeSmcY7DaH_J4I2ojQR4Ljeaj4ywnV-AvV8uX8osivccNRe5haKolMCxQA4O4m828dwyjBYh9BuIM9UZiWzgiqdUb7vig4eH4LiZxaDLZ5RxHPl5V_tNJAbtFnW4Yo8sUlZxyIcDYV3kUic7u7vbswy3Us/http%3A%2F%2Fverisigninc.com%2F>
    >
    > On 9/16/22, 9:17 PM, "regext on behalf of Gavin Brown" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:
    >
    > Hi Thomas,
    >
    > Thanks for the suggestions. I will add them to the next version.
    >
    > G.
    >
    > > On 15 Sep 2022, at 01:11, Thomas Corte (TANGO support) <[e-mail]<mailto:[e-mail]>> wrote:
    > >
    > > On 9/14/22 13:35, Gavin Brown wrote:
    > >
    > >> Greetings all,
    > >>
    > >> Many years ago CentralNic had a proprietary EPP extension for managing
    > >> the TTL values of domain names. ...
    > >>
    > >> However I've had a bit of feedback about the draft since then, so I've
    > >> just published a new version and am now sharing it with the WG for
    > >> feedback.
    > >
    > > I have two comments:
    > >
    > > 1) The specification should probably address the effect of the TTLs on
    > > IDN variants. If a registry supports IDN variants as attributes of a
    > > domain name (either automatically added or via an extension), they will
    > > usually add some DNS records dedicated to these variants to the TLD zone,
    > > so the spec should specify that the same TTL is applied to these
    > > dedicated records as well. If IDN variants are managed as their own
    > > objects, they can receive their own specific TTL values.
    > >
    > > 2) I'd suggest to add this boilerplate text (or something similar) to the
    > > draft:
    > >
    > > "EPP uses XML namespaces to provide an extensible object management
    > > framework and to identify schemas required for XML instance parsing
    > > and validation. These namespaces and schema definitions are used to
    > > identify both the base protocol schema and the schemas for managed
    > > objects. The XML namespace prefixes used in examples (such as the
    > > string "ttl" in "xmlns:ttl") are solely for illustrative purposes. A
    > > conforming implementation MUST NOT require the use of these or any
    > > other specific namespace prefixes."
    > >
    > > This is a pet peeve of mine, as some registries still haven't managed to
    > > implement this correctly.
    > >
    > >> In our implementation, glue records are only published if the
    > >> superordinate domain is delegated to them, and the current
    > >> specification assumes the same design choice. However this is
    > >> obviously not true for other registries, so being able to change the
    > >> TTL on a host object independently of the superordinate domain may be
    > >> needed to account for scenarios where the client wishes to change the
    > >> TTL of all NS records *except* those of the superordinate domain.
    > >> However I am not sure if this is a scenario that justifies the
    > >> additional complexity entailed - but I'd appreciate the list's input
    > >> on that point.
    > >
    > > Our own TANGO system's zone generation also suppresses glue records if
    > > they're unnecessary, so I'd agree that the extra complexity shouldn't be
    > > required.
    > >
    > > Best regards,
    > >
    > > Thomas
    > >
    > > --
    > > TANGO REGISTRY SERVICES®
    > > Knipp Medien und Kommunikation GmbH Thomas Corte
    > > Technologiepark Phone: [phone]
    > > Martin-Schmeisser-Weg 9 Fax: [phone]
    > > D-44227 Dortmund E-Mail: [e-mail]<mailto:[e-mail]>
    > > Germany
    > >
    > >
    > >
    > >
    > >
    >
    > --
    > Gavin Brown
    > Head of Registry Services
    > CentralNic Group plc (LSE:CNIC)
    > https://secure-web.cisco.com/14iQKw6gpSA8BoJOmhv6QjiaCTMGaV1jtoe_uIp8bRMky-K_waMharMEg1LYAtlWQzbHVPm2AmR56O6ydcDKobgVBEd8Mp95GJ4pfxuUZclcuaVBTXohuG6UFiZL8xJ3nqGu2mdmXKQsJPMkec8furVUgjMJNBPl8lwD5Bq0rklXDq-hFZXWTKZmWa5fb8Uwnk0OsfYNX4uZhal8J_rCVACHGBTdRrXemWcsjenM7fbYJzUttkEdStu8R7PY547eg/https%3A%2F%2Fcentralnicregistry.com
    >
    > Cal: https://secure-web.cisco.com/1hJ_Ypbd5OAM--cIUke4ujR8-8LTMV4cqpfYs9QUL3-xaEmFm7OPW_RKJa5TaJZ-HneITtwkOeMVSKTCbmrMbjcErDdz8Dn9s8KdDKMHHT_n0P5y-9uAWYPonAmrg9XVm72gORCQ9yh_SEzHxdAInQcg2pxTqBSDiW21bw4Msfzp7DQlftiKFeHB_z6wxjFlsu1gkcEBSt3buj5OUNEPih8pWx70nO2sXSue_OSN30cn26q27kvkyDHix9BcqlRSV/https%3A%2F%2Fcnic.link%2Fgbcalendar
    >
    > CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR.
    >
    > https://secure-web.cisco.com/1dbi9wWVJ28DEfKsxyfgDEQU-jFqu7mdY6XAsqbxvETOtZUTia8UHVG3wWzYeRemA7OPimBJnEWIQ_chpT9e5Sa-J20mZ-lg7OKtsrHauuCHNraZIrO2sRn6I4uLLUnXzu7GzOmhVsqGk-bob53BCqaJDheGvFW_lx1FJtJFFdvwqJk7jnOmAXoXJh9o7jqHERzAzFZQabrHdQPUpCk_gViXXZQ3itKXVeka3mdJHHng6f07BY0VfTk3jZ8prKebY/https%3A%2F%2Fwww.centralnic.com
    >
    > _______________________________________________
    > regext mailing list
    > [e-mail]<mailto:[e-mail]>
    > https://secure-web.cisco.com/17iGVT_AU5IsvLflCUT5ypMVunmm1fTgnPxEcMeRIVbSjVZJoJIWdWHyw157N9qknJiHgZkxVaZWRtrflXFk_7WtXpCWF_Gwe7PdF_lmQJh07SRN5vMVGi3XbZKgIdtWTMfx3R-diYwdR5a2_tC-ByoLYtPrGe7Mnivy3oZbVWZlEGNeiP0fE_5Nccxc5kNkVoPC0hdk-f9gyPQAaiVMskLu5OoHGs-thMpK2RAklTTuW5nbCC9f53GvnO4SlCwKo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
    >
    > _______________________________________________
    > regext mailing list
    > [e-mail]<mailto:[e-mail]>
    > https://secure-web.cisco.com/1uk2fr6SbgeYDiRtLSfE1gPeoIP4OayW3D3MTev2AuxEowvJhHH5o8fP6ofVKpbYk9eTqZ6S_bmtbQDKx6fUf7P0ImAG5so__X7EpvZHBGu0GQA8PzfkmDBeu9g4bXGCQGT1ysLBknZZg_7-n-dHO5uk8_hYLo-fuzU_ybXQyiqzl69mzdnKeapHFIPRb3TeJWcErjbiXngDHUvXL5Ur1C6UaheiImxW8XMzN-XaVOPVP-cCFSMh1GMJa1ZRxmBla/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
    >

    --
    Gavin Brown
    Head of Registry Services
    CentralNic Group plc (LSE:CNIC)
    https://secure-web.cisco.com/1lktPhnXJ36QcWwB_nWDEJX9acgMw_YC_GzImtZ2c5yvEGow5GLZMQ0ORxKlFsxwT51e51Wp2-pgNTSc8_HV_jVGV0W8gJCGuEUvxLe7cjMooPXHRuuTmHphXBiz06r5oP2oMPVE5cMWm29pkLEVLfdvPL9UfUMlurzdH8E6VBTvAjOVEM_CInVFIOc1gnXi918T4uyFvu7N52YFOPOoCVqUbZF6_zzx8fZ_xK1Nsf1a6iJubj2RqsEZZZXNV9oA7/https%3A%2F%2Fcentralnicregistry.com

    Cal: https://secure-web.cisco.com/1lWudxzTziTfT5hvKxlPQaNV-2-MrZRMowg9M6FcmrV_lz70NlhT-i43go4JssAwqRncGzIeaczGpjsJ6YPNNgZMp9RYvNH1_A7fLus-n8dClA7yXy65qmTS_xx2CT4V85u1RP-AhKqBnqJ4HGXvI8nYCIE0FdGSPaM6GJl-Tx914ebRVnyU3Zo7TatfJnujyZDo5KeyAklCr5bxK64X7bMaKoCCG884wb3OgzjkXciohIki5KfWTZ-ugD4kFRCY0/https%3A%2F%2Fcnic.link%2Fgbcalendar

    CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR.

    https://secure-web.cisco.com/14_4cnKxNaqSyp1oKSQfhdnzhHvyxCD2B0Gk1eOyOeEJtIaTWO3IgtpdDX8gtW75lANjmeH_mrNdl0n8N1ruZgDVkcXp7j7mZMeocw4Hziv5o4efgOflfVzaflSEmswIhMqtWUrYvOQiiSkqAI_tR1TNoCVzbDmQV5vF3Tdxr3LMABlhGn5Z3e53Ku1gkVPGMPdHLfTDxCgGRHFkgcr6fVnODqsvP6DW4g-lufDNjPJEoErcVCqlYNats-NU4rl4K/https%3A%2F%2Fwww.centralnic.com


_______________________________________________
regext mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1JVzWZFwxU3jQdy0TZHSECCBmGcY_u4kdw-mvv4ZcUKGK7dNZXdBe1Ym4Y8fiJRxiPc1CmcjSkuKGxjSawUX4MlqTTLPX0X1_N7idCRpcYLVXKHA70lxSNK8nBUkzCtrcPW7htKTgh00CunnuQCCurCYH3bUoDArRq68z0JE85xtoVJPND4aLDILpig6KX2OOfa9uU1KInql14NY5aCmFHh_5b1y-u-yzoe3KgQ8Tcoadt26_tuD7PqYPgcAsa4Tb/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>