[DNSOP] Re: AD review of draft-ietf-dnsop-rfc8624-bis-05

[Warren Kumari]

On Tue, Feb 18, 2025 at 6:55 AM, Eric Vyncke <
evyncke=40cisco@dmarc.ietf.org> wrote:

>
>
> Dear all,
>
>
>
> Thanks for your patience as I was on vacations when the publication of
> this I-D was requested.
>

No worries, and thanks.
Apologies for my mail client having renumbered the ordered list — it thinks
it was being helpful….


As the DNSOP responsible AD is also an author, I was selected as the acting
> responsible AD for this I-D. Hence, here are some comments that I want to
> be addressed (either by replying to me or by a revised I-D) before
> proceeding to the IETF Last Call.
>
>
>
>
>
>1. The shepherd write-up is very terse , so far so good, but does not
>include a justification for the intended status (PS is the correct one of
>course) or whether cited authors agree to be authors
>2. The id-nits tool indicates several issues to be fixed, notably
>fixing the the update meta-data tag
>
>
Thanks; done.


>3. Abstract, is there a missing “and” in ` This is done both to allow
>the list to be more easily updated, to allow the list to be more easily
>referenced`
>
>
Thanks; done.


>3. Section 1.1, suggest adding a reference to the IANA **registries**
>and not **tables** in addition to citing the names of the registries
>
>
Done.

I spent some time looking into the correct terminology and explored a run
rabbit-hole.  We have rewritten it as:

   The columns added to the IANA "DNS Security Algorithm Numbers"
   [DNSKEY-IANA] and "DNSSEC Delegation Signer (DS) Resource Record (RR)
   Type Digest Algorithms" [DS-IANA] registries target DNSSEC operators
   and implementers.

(technically "DNS Security Algorithm Numbers"  seems to be a subregistry of
the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry, but
the IANA guidance is that "You should almost always use the term "registry"
to refer to a table or collection of assignments made for a common
identifier type").

>
>4. Section 1.1, to be honest, I have no clue what is meant by ` the
>risk of algorithm compromise` ...or do you mean a vulnerability discovered
>in a crypto algo ?
>
>
Thank you, how is:
"Implementations need to be conservative in the selection of
   algorithms they implement in order to minimize both code complexity
   and the cryptographic attack surface."




>5. Section 1.1 s/ be less secure *then* originally thought/ be less
>secure *than* originally thought/ and s/ In general it/ In general*,* it/
>
>
Doh! Done. Schooled by a non-native English speaker :-P



>6. Section 1.1 s/ which algorithms should be deploy / which algorithms
>should be deploy*ed* / ?
>
>
Thanks; Done!


>7. Even if not a SHOULD, readers will welcome to read what are the
>consequences of bypassing this should or when the should can be bypassed.
>8. Section 1.2, as “deprecated” is rather vague in the IETF context,
>suggest explaining what is meant by deprecated in this document
>9. Section 1.3 I like your last paragraph ;-)
>
>
Yay!


>10. Section 2, I think that the right IANA terms are registries/fields
>and not tables/columns (same comments at multiple places)
>
> It looks like you are technically correct ("The best kind of correct") for
the tables vs registries bit, but RFC8126 - "Guidelines for Writing an IANA
Considerations Section in RFCs"
 seems
to say that "column" is the correct term for, er, well, a column…..
So I s/table/registry/, but not s/column/field/.



>11. Section 2, suggest using “MAY” when it is a value to clearly
>separate from the BCP14 MAY
>
> Done.

>
>12. Section 2, I am completely unclear about the justification of a
>BCP14 MAY in `MAY requires a Standards Action`. I think that some
>justification for the MAY will be welcome/
>
>
Thank you, we have added justification to the draft.


>12. Section 4, where is “*” definition in table 3 ?
>
>
That is defined in the existing registry (
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml),
and says:
"* There has been no determination of standardization of the use of this
algorithm with Transaction Security. "



>14. Sections 3 and 4, suggest splitting the first paragraph in two
>sentences as the audience is different: IANA then operators.
>
>
Done, thanks.


>15. Section 5 s/ Thus the security/ Thus*,* the security/
>
>

Thanks, done.


>16. Sections 2 & 7, I find it strange to find IANA policies and values
>in section 2 and having a reference to this section 2 in the actual IANA
>considerations (section 7). This would require some heavy text change, but
>I sincerely believe that this will be clearer.
>
>

Thank you; we have discussed this with the IANA, and they are OK with it.
Basically, the entire document is all about updating IANA information, and
so the IANA considerations section just points at the rest of the document…

While we *could* reorganize the

[DNSOP] Re: AD review of draft-ietf-dnsop-must-not-ecc-gost-02

[Warren Kumari]

On Mon, Feb 17, 2025 at 11:15 AM, Eric Vyncke <
evyncke=40cisco@dmarc.ietf.org> wrote:

> Dear all,
>
>
>
> Thanks for your patience as I was on vacations when the publication of
> this I-D was requested. As the DNSOP responsible AD is also an author, I
> was selected as the acting responsible AD for this I-D. Hence, here are
> some comments that I want to be addressed (either by replying to this email
> or by a revised I-D) before proceeding to the IETF Last Call.
>
>
>
>1. The shepherd write-up is very terse , so far so good, but does not
>include a justification for the intended status (PS is the correct one of
>course) and is unclear whether authors have accepted to be cited as authors
>(even if I guess so)
>2. Even if RFC 5933 is already marked historic, let’s be clear and add
>meta-data and text in abstract/introduction/and shepherd write-up that this
>I-D deprecates RFC 5933
>
>
Done, but I'm not convinced this is a good idea. I added a note:

[RFC Editor: please remove this before publication: It is unclear if updating
RFC5933 (a Historic document) is the correct thing to do or not. We did it
so that it shows up in Datatracker and similar, but this may be a
mistake. We are happy to change this if the RFC Editor / IESG / whoever thinks
this is a bad idea.]


>3. Section 4, even if the “should” are not in uppercase, adding the
>consequences of not following the “should” should be explained
>
>
Thank you, done.



>4. RFC 9499 appears as a reference but is not cited, please remove it
>
>
Thanks, done.


>
> Once the above points are addressed, I am proceeding with the publication
> of this important document.
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
>
>
>
>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] I-D Action: draft-ietf-dnsop-rfc8624-bis-06.txt

[internet-drafts]

Internet-Draft draft-ietf-dnsop-rfc8624-bis-06.txt is now available. It is a
work item of the Domain Name System Operations (DNSOP) WG of the IETF.

   Title:   DNSSEC Cryptographic Algorithm Recommendation Update Process
   Authors: Wes Hardaker
Warren Kumari
   Name:draft-ietf-dnsop-rfc8624-bis-06.txt
   Pages:   13
   Dates:   2025-02-18

Abstract:

   The DNSSEC protocol makes use of various cryptographic algorithms to
   provide authentication of DNS data and proof of non-existence.  To
   ensure interoperability between DNS resolvers and DNS authoritative
   servers, it is necessary to specify both a set of algorithm
   implementation requirements and usage guidelines to ensure that there
   is at least one algorithm that all implementations support.  This
   document updates RFC8624 by moving the canonical source of algorithm
   implementation requirements and usage guidance for DNSSEC from
   RFC8624 to an IANA registry.  This is done both to allow the list to
   be more easily updated, and to allow the list to be more easily
   referenced.  Future extensions to this registry can be made under
   new, incremental update RFCs.

   The document does not change the status (MUST, MAY, RECOMMENDED, etc)
   of any of the algorithms listed in RFC8624; that is the work of
   future documents.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8624-bis-06

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8624-bis-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: AD review of draft-ietf-dnsop-rfc8624-bis-05

[Eric Vyncke (evyncke)]

Hello Warren,

Thanks for the quick reply and revised I-D. We agree on all points, and I will 
proceed shortly with the IETF Last Call, some more comments below as EV>

Regards

-éric

From: Warren Kumari 
Date: Tuesday, 18 February 2025 at 23:35
To: Eric Vyncke (evyncke) 
Cc: dnsop@ietf.org 
Subject: Re: [DNSOP] AD review of draft-ietf-dnsop-rfc8624-bis-05



5. Section 1.1 s/ be less secure *then* originally thought/ be less secure 
*than* originally thought/ and s/ In general it/ In general*,* it/

Doh! Done. Schooled by a non-native English speaker :-P

EV> it happens sometimes ;-)



10. Section 2, I think that the right IANA terms are registries/fields and not 
tables/columns (same comments at multiple places)
It looks like you are technically correct ("The best kind of correct") for the 
tables vs registries bit, but RFC8126 - "Guidelines for Writing an IANA 
Considerations Section in RFCs" 
seems to say that "column" is the correct term for, er, well, a column…..
So I s/table/registry/, but not s/column/field/.

EV> fair enough



12. Section 4, where is “*” definition in table 3 ?

That is defined in the existing registry 
(https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml), 
and says:
"* There has been no determination of standardization of the use of this 
algorithm with Transaction Security. "

EV> suggest to add some text


16. Sections 2 & 7, I find it strange to find IANA policies and values in 
section 2 and having a reference to this section 2 in the actual IANA 
considerations (section 7). This would require some heavy text change, but I 
sincerely believe that this will be clearer.


Thank you; we have discussed this with the IANA, and they are OK with it.
Basically, the entire document is all about updating IANA information, and so 
the IANA considerations section just points at the rest of the document…

While we *could* reorganize the whole document, I think that it would actually 
end up confusing.

EV> If IANA is fine with the flow, who am I to propose something else ? 😊


18. Section 7.2 I think it is either ` Update the registration policy for the 
[DS-IANA] registry to match the 
text describing update requirements above.

19. ` (unclear what the “above” means here) or ` the registration policy for 
the [DS-IANA] registry should 
match the text in describing the requirements in Section 2 of this document`

Wow, good catch. We have fixed these…

EV> I have not seen any change in the I-D though about the vague “above”...

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: AD review of draft-ietf-dnsop-must-not-sha1-02

[Warren Kumari]

On Mon, Feb 17, 2025 at 10:01 AM, Eric Vyncke <
evyncke=40cisco@dmarc.ietf.org> wrote:

> Dear all,
>
>
>
> Thanks for your patience as I was on vacations when the publication of
> this I-D was requested.
>

Thanks, an no worries…


As the DNSOP responsible AD is also an author, I was selected as the acting
> responsible AD for this I-D. Hence, here are some comments that I want to
> be addressed (either by replying to me or by a revised I-D) before
> proceeding to the IETF Last Call.
>
>
>
>1. The shepherd write-up is very terse , so far so good, but does not
>include a justification for the intended status (PS is the correct one of
>course)
>2. Should this document update (in the meta-data, abstract, and
>introduction) RFCs 4034 and 5155 ? (I think so)
>
>
Thank you, done!


>3. The phrasing of the last paragraph section 2 is weird with a mix of
>MUST and MAY
>
>
Thank you, done!


>3. Section 5  "Digest Algorithms" registry, there is a Status field
>but no "Use for DNSSEC Delegation" field
>4. Section 5 s/DNS Security Algorithm Numbers registry/“DNS Security
>Algorithm Numbers” registry/ and there is no “MUST NOT” value, just “N”
>
>
>

Awesome, thank you, we are not addressing these, and your later mail noted
that they are moot.

Additionally, and for the record, yes, both Wes and I are OK being cited as
authors…

W


Once the above points are addressed, then I will proceed with the
> publication of this important document.
>
>
> Regards,
>
>
>
> -éric
>
>
>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] I-D Action: draft-ietf-dnsop-must-not-sha1-03.txt

[internet-drafts]

Internet-Draft draft-ietf-dnsop-must-not-sha1-03.txt is now available. It is a
work item of the Domain Name System Operations (DNSOP) WG of the IETF.

   Title:   Deprecating the use of SHA-1 in DNSSEC signature algorithms
   Authors: Wes Hardaker
Warren Kumari
   Name:draft-ietf-dnsop-must-not-sha1-03.txt
   Pages:   6
   Dates:   2025-02-18

Abstract:

   This document deprecates the use of the RSASHA1 and
   RSASHA1-NSEC3-SHA1 algorithms for the creation of DNSKEY and RRSIG
   records.

   It updates RFC4034 and RFC5155 as it deprecates the use of these
   algorithms.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-sha1/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-must-not-sha1-03

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-must-not-sha1-03

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] I-D Action: draft-ietf-dnsop-must-not-ecc-gost-03.txt

[internet-drafts]

Internet-Draft draft-ietf-dnsop-must-not-ecc-gost-03.txt is now available. It
is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.

   Title:   Deprecate usage of ECC-GOST within DNSSEC
   Authors: Wes Hardaker
Warren Kumari
   Name:draft-ietf-dnsop-must-not-ecc-gost-03.txt
   Pages:   5
   Dates:   2025-02-18

Abstract:

   This document retires the use of ECC-GOST within DNSSEC.

   RFC5933 (now historic) defined the use of GOST R 34.10-2001 and GOST
   R 34.11-94 algorithms with DNS Security Extensions (DNSSEC).  This
   document updates RFC5933 by deprecating the use of ECC-GOST.

   [RFC Editor: please remove this before publication: It is unclear if
   updating RFC5933 (a Historic document) is the correct thing to do or
   not.  We did it so that it shows up in Datatracker and similar, but
   this may be a mistake.  We are happy to change this if the RFC Editor
   / IESG / whoever thinks this is a bad idea.]

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-ecc-gost/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-must-not-ecc-gost-03

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-must-not-ecc-gost-03

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: AD review of draft-ietf-dnsop-must-not-ecc-gost-02

[Eric Vyncke (evyncke)]

Thank you, Warren, for your replies on the 3 related I-Ds, I will proceed 
shortly with the IETF Last Call.

About deprecating an already historic RFC, I am unsure as well as those 2 terms 
are not really well defined. Let’s see what the IESG/RFC Editor say indeed, 
smart idea to add this note in the text.

-éric


From: Warren Kumari 
Date: Tuesday, 18 February 2025 at 23:39
To: Eric Vyncke (evyncke) 
Cc: dnsop@ietf.org 
Subject: Re: [DNSOP] AD review of draft-ietf-dnsop-must-not-ecc-gost-02




On Mon, Feb 17, 2025 at 11:15 AM, Eric Vyncke 
mailto:evyncke=40cisco@dmarc.ietf.org>> 
wrote:
Dear all,

Thanks for your patience as I was on vacations when the publication of this I-D 
was requested. As the DNSOP responsible AD is also an author, I was selected as 
the acting responsible AD for this I-D. Hence, here are some comments that I 
want to be addressed (either by replying to this email or by a revised I-D) 
before proceeding to the IETF Last Call.


1. The shepherd write-up is very terse , so far so good, but does not 
include a justification for the intended status (PS is the correct one of 
course) and is unclear whether authors have accepted to be cited as authors 
(even if I guess so)

2. Even if RFC 5933 is already marked historic, let’s be clear and add 
meta-data and text in abstract/introduction/and shepherd write-up that this I-D 
deprecates RFC 5933

Done, but I'm not convinced this is a good idea. I added a note:


[RFC Editor: please remove this before publication: It is unclear if updating

RFC5933 (a Historic document) is the correct thing to do or not. We did it

so that it shows up in Datatracker and similar, but this may be a

mistake. We are happy to change this if the RFC Editor / IESG / whoever thinks

this is a bad idea.]

3. Section 4, even if the “should” are not in uppercase, adding the 
consequences of not following the “should” should be explained

Thank you, done.



4. RFC 9499 appears as a reference but is not cited, please remove it

Thanks, done.


Once the above points are addressed, I am proceeding with the publication of 
this important document.

Regards,

-éric



___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to 
dnsop-le...@ietf.org

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Reminder: (in 2 HOURS) DNSOP Virtual Interim Meeting 17 February 2025

[Michael De Roover]

On Monday, February 17, 2025 1:54:34 PM CET Suzanne Woolf wrote:
> Good morning/afternoon/evening. We’re resending this announcement to get it
> to the top of everyone’s Monday mailbox. DNSOP interim starts in 2 hours,
> at 20:00 UTC. Agenda and Meetecho link below.
> 
> See you there,
> Suzanne, Tim, and Benno

Hi Benno, Suzanne, Tim, and DNSOP,

Unfortunately I couldn't make it to the virtual meeting for scheduling reasons 
(had to get groceries, likely wouldn't have spoken), but I appreciate that the 
session has been recorded and published. That's going to be my lecture for 
tonight, thank you!

-- 
Met vriendelijke groet,
Michael De Roover

Mail: i...@nixmagic.com
Web: michael.de.roover.eu.org


___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] AD review of draft-ietf-dnsop-rfc8624-bis-05

[Eric Vyncke (evyncke)]

Dear all,

Thanks for your patience as I was on vacations when the publication of this I-D 
was requested. As the DNSOP responsible AD is also an author, I was selected as 
the acting responsible AD for this I-D. Hence, here are some comments that I 
want to be addressed (either by replying to me or by a revised I-D) before 
proceeding to the IETF Last Call.


  1.  The shepherd write-up is very terse , so far so good, but does not 
include a justification for the intended status (PS is the correct one of 
course) or whether cited authors agree to be authors
  2.  The id-nits tool indicates several issues to be fixed, notably fixing the 
the update meta-data tag
  3.  Abstract, is there a missing “and” in ` This is done both to allow the 
list to be more easily updated, to allow the list to be more easily referenced`
  4.  Section 1.1, suggest adding a reference to the IANA *registries* and not 
*tables* in addition to citing the names of the registries
  5.  Section 1.1, to be honest, I have no clue what is meant by ` the risk of 
algorithm compromise` ...or do you mean a vulnerability discovered in a crypto 
algo ?
  6.  Section 1.1 s/ be less secure *then* originally thought/ be less secure 
*than* originally thought/ and s/ In general it/ In general*,* it/
  7.  Section 1.1 s/ which algorithms should be deploy / which algorithms 
should be deploy*ed* / ? Even if not a SHOULD, readers will welcome to read 
what are the consequences of bypassing this should or when the should can be 
bypassed.
  8.  Section 1.2, as “deprecated” is rather vague in the IETF context, suggest 
explaining what is meant by deprecated in this document
  9.  Section 1.3 I like your last paragraph ;-)
  10. Section 2, I think that the right IANA terms are registries/fields and 
not tables/columns (same comments at multiple places)
  11. Section 2, suggest using “MAY” when it is a value to clearly separate 
from the BCP14 MAY
  12. Section 2, I am completely unclear about the justification of a BCP14 MAY 
in `MAY requires a Standards Action`. I think that some justification for the 
MAY will be welcome/
  13. Section 4, where is “*” definition in table 3 ?
  14. Sections 3 and 4, suggest splitting the first paragraph in two sentences 
as the audience is different: IANA then operators.
  15. Section 5 s/ Thus the security/ Thus*,* the security/
  16. Sections 2 & 7, I find it strange to find IANA policies and values in 
section 2 and having a reference to this section 2 in the actual IANA 
considerations (section 7). This would require some heavy text change, but I 
sincerely believe that this will be clearer.
  17. Sections 7.1 and 7.2 s/ These values should be populated / These values 
must be populated / and s/ should match / must match /
  18. Section 7.2 I think it is either ` Update the registration policy for the 
[DS-IANA] registry to match the 
text describing update requirements above.
  19. ` (unclear what the “above” means here) or ` the registration policy for 
the [DS-IANA] registry should 
match the text in describing the requirements in Section 2 of this document`
  20. Section 8 s/ The content*s* of this document was heavily discussed/ The 
content of this document was heavily discussed/
  21. Section 8 s/we/the authors/ ?
  22. References RFC 9364 seems more informative than normative to me, less 
assertive though on RFC 8624 as it is borderline to be informative only


Once the above points are addressed, then I will proceed with the publication 
of this important document. I will make sure that the 3 IETF Last Calls and the 
IESG ballots indicate the right reading order among the 3 Warren & Wes I-Ds 
;-), i.e., start with this one (and not ending by this one as I did...).

Regards,

-éric

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: RFC for web3 wallet mapping using DNS

[Shay C]

I have made a new draft
https://datatracker.ietf.org/doc/draft-chins-dnsop-web3-wallet-mapping/

   - Separated the forward mapping and reverse mapping.  Will propose a ID
   for reverse mapping separately.
   - Removed DEFAULT record because it had the potential to return
   incorrect records

Cheers
Shay

On Sun, Nov 17, 2024 at 9:49 PM Shay C  wrote:

> The WALLET RRtype is already assigned as a DNS parameter
>
> https://www.iana.org/assignments/dns-parameters/WALLET/wallet-completed-template
>
> We are trying to get consensus on the operational usage of that RRtype.
> The TXT record fallback is also included as well as reverse lookup
> mechanisms.
>
> On Sun, Nov 17, 2024 at 6:20 AM Petr Menšík  wrote:
>
>> Why don't we use URI instead? Maybe with prefix _wallet? Is introduction
>> of a new type necessary, when it seems like scheme:address format anyway?
>>
>> On 18/09/2024 17:44, Dave Lawrence wrote:
>> > Joe Abley writes:
>> >>> Would it be recommended to do a proposal that use either RRtype
>> >>> (TXT or WALLET) or choose one?
>> >> I haven't read your proposal and don't have an opinion on that. I
>> >> agree that it sounds like a good question for you to ask yourself.
>> > You don't have an opinion on using TXT?
>> >
>> > I'm somewhat surprised by this.
>> >
>> > ___
>> > DNSOP mailing list -- dnsop@ietf.org
>> > To unsubscribe send an email to dnsop-le...@ietf.org
>>
>> --
>> Petr Menšík
>> Software Engineer, RHEL
>> Red Hat, https://www.redhat.com/
>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>>
>> ___
>> DNSOP mailing list -- dnsop@ietf.org
>> To unsubscribe send an email to dnsop-le...@ietf.org
>>
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org