Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Wessels, Duane]

> On Mar 29, 2023, at 10:53 AM, Shumon Huque  wrote:
> 
> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:
> 
> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
> 
> 
> On 3/28/23 03:14, Shumon Huque wrote:
> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni  > > wrote:
> > 
> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > Can we at least state that domains with cyclic dependencies are a bad
> > idea, and may not be supported by all resolvers.  In other words, that
> > the domain owner can't **rely** on the sibling glue recommended to be
> > sent in this draft to save the day.
> > 
> > My strong preference is still to delete all reference in the draft to
> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> > sibling glue primarily as a performance optimisation, and secondarily
> > as a last resort when the nameserver IP addresses are wrong or gone
> > from the authoritative zone (another bad practice).
> > 
> > 
> > Viktor - I've so far not seen many other people speak up in support of your
> > position. I suspect this is because this draft was discussed to death many
> > months ago during long discussion threads on the list, and there is likely
> > already rough consensus for the current content. Personally, I would be ok
> > with adding a statement that configurations involving cyclic dependencies
> > are not recommended, but others will likely have to also speak up in support
> > of this too.
> 
> I support adding such a statement about cyclic dependencies.
> 
> As do I. 
>  
> 
> In addition, I would support saying that data suggests that, while 
> (non-cyclic) glue records may have a benefit in certain cases, they 
> frequently are a source of harm (time-outs), and the trade-off remains 
> unclear.
> 
> I would support this as well.
> 
> In my anecdotal experience as an operator, I routinely encounter mismatches 
> in sibling glue and child zone NS sets that appear to be due to the glue 
> being forgotten.  My assumption is that, because it's not necessary to 
> operate, when operators fail to update it they don't receive any kind of 
> signal that something is wrong.
> 
> Viktor's numbers are pretty clear data, though, so nobody should need my 
> anecdotes to be convinced.  While sibling glue may be a useful optimisation 
> in some cases, given how poorly maintained it is it seems to cause more 
> problems than it solves.
> 
> 
> I'd like to remind folks that the scope of this draft when it was adopted by 
> the working group was very narrow. Mainly to say that 'required' glue must 
> set TC=1 if it doesn't fit into the DNS response payload. That required 
> talking about other types of non-mandatory glue like sibling, but has not 
> proposed to change authoritative server behavior in those areas.
> 
> If folks want to deprecate sibling glue entirely, it would be best to write 
> another draft saying that and see if we can get consensus on that.
> 

I agree with this position.  The scope of the draft is about message size and 
behavior when glue records don’t fit.  Although the “glue is not optional” name 
is catchy, in hindsight I think a different name would better reflect the 
intent of the document.

DW


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Shumon Huque]

On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:

>
> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
>
>>
>>
>> On 3/28/23 03:14, Shumon Huque wrote:
>> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni > > wrote:
>> >
>> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
>> > Can we at least state that domains with cyclic dependencies are a
>> bad
>> > idea, and may not be supported by all resolvers.  In other words,
>> that
>> > the domain owner can't **rely** on the sibling glue recommended to
>> be
>> > sent in this draft to save the day.
>> >
>> > My strong preference is still to delete all reference in the draft
>> to
>> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
>> > sibling glue primarily as a performance optimisation, and
>> secondarily
>> > as a last resort when the nameserver IP addresses are wrong or gone
>> > from the authoritative zone (another bad practice).
>> >
>> >
>> > Viktor - I've so far not seen many other people speak up in support of
>> your
>> > position. I suspect this is because this draft was discussed to death
>> many
>> > months ago during long discussion threads on the list, and there is
>> likely
>> > already rough consensus for the current content. Personally, I would be
>> ok
>> > with adding a statement that configurations involving cyclic
>> dependencies
>> > are not recommended, but others will likely have to also speak up in
>> support
>> > of this too.
>>
>> I support adding such a statement about cyclic dependencies.
>>
>
> As do I.
>

>
>>
>> In addition, I would support saying that data suggests that, while
>> (non-cyclic) glue records may have a benefit in certain cases, they
>> frequently are a source of harm (time-outs), and the trade-off remains
>> unclear.
>>
>
> I would support this as well.
>
> In my anecdotal experience as an operator, I routinely encounter
> mismatches in sibling glue and child zone NS sets that appear to be due to
> the glue being forgotten.  My assumption is that, because it's not
> necessary to operate, when operators fail to update it they don't receive
> any kind of signal that something is wrong.
>
> Viktor's numbers are pretty clear data, though, so nobody should need my
> anecdotes to be convinced.  While sibling glue may be a useful optimisation
> in some cases, given how poorly maintained it is it seems to cause more
> problems than it solves.
>
>
I'd like to remind folks that the scope of this draft when it was adopted
by the working group was very narrow. Mainly to say that 'required' glue
must set TC=1 if it doesn't fit into the DNS response payload. That
required talking about other types of non-mandatory glue like sibling, but
has not proposed to change authoritative server behavior in those areas.

If folks want to deprecate sibling glue entirely, it would be best to write
another draft saying that and see if we can get consensus on that.

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-01.txt

[Paul Wouters]

On Tue, 28 Mar 2023, Alex Stuart wrote:


I am employed by a SAML metadata registrar and we require verification that a 
registrant has effective control over a fully-qualified domain name. We have 
developed our own DNS TXT based method for verification and are in the process 
for reviewing it. We would like to be able to refer to a BCP document, and 
appreciate your work towards one.


That's great!


Here are some questions and comments as feedback on 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-01.
 I hope they are useful.

1. In section 2, you define the APEX, although this term does not appear in the 
rest of the document. All the examples show how to verify the apex domain 
example.com. It is therefore unclear to me whether your technique can be used 
to verify effective control over an arbitrary fully-qualified domain name. Can 
the specification generalise?


It can be used for any FQDN, as long as you prefix it deeper into that
name. Generally, people want to know about the "whole domain", so the
examples use this (the apex). We can add some clarifying text.


2. The examples in Section 3.1 show provider-relevant prefixes which start with 
an underscore. Is this convention or a requirement?


A good question, and omission at your part. We will also clarify
this in the document.  The use of underscore comes from the fact that
it is a legal character in DNS, but technically not valid for "host
names". So using an underscore means we avoid all risk of clashing our
"infrastructure" records with regular records. For example, if we used
"ownership.example.com" instead of "_ownership.example.com", than anyone
using a website "ownership.example.com" might have a hard time using
their name and the verification method at once.


3. In Section 3.1 you say "Consumers of the provider services need to relay 
information from a provider's website to their local DNS administrators". There are 
other ways to relay the information from provider to consumer, such as S/MIME, and the 
specification should reflect this.


Will fix.


4. Section 3.1 states "Providers MUST provide clear instructions on when a verifying record 
can be removed" and A.1.4 has "The service provider doing the verification should specify 
how long the verification will take". In my experience, the most variable part of the process 
is at the consumer end, because the person wishing to use the service is not typically the DNS 
admin. An expiry set solely by the provider doesn't take that variability into account. Maybe it's 
better for the provider to signal a period after which the verification would be assumed 
unsuccesful, and to provide guidance to the provider not to make this period too short.


We will clarify this. The issue we are talking about is not the
"verification period" until the first verification succeeds, but
whether the record is re-used at regular intervals to continue
the proof of ownership.


5. My employer's method currently requires the registrant to set a TXT record 
on the apex domain. Thank you for providing 2 reasons in A.1.1 why we should 
not.


Excellent! I'm happy to see we are already seeing good results from the draft! 
:)

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-01.txt

[Alex Stuart]

Dear participants of the DNSOP mailing list,

I would like to respond to the thread in the subject. Having joined this 
mailing list a few hours ago, it's difficult to reply at the correct part of 
the thread.

I am employed by a SAML metadata registrar and we require verification that a 
registrant has effective control over a fully-qualified domain name. We have 
developed our own DNS TXT based method for verification and are in the process 
for reviewing it. We would like to be able to refer to a BCP document, and 
appreciate your work towards one.

Here are some questions and comments as feedback on 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-01.
 I hope they are useful.

1. In section 2, you define the APEX, although this term does not appear in the 
rest of the document. All the examples show how to verify the apex domain 
example.com. It is therefore unclear to me whether your technique can be used 
to verify effective control over an arbitrary fully-qualified domain name. Can 
the specification generalise?

2. The examples in Section 3.1 show provider-relevant prefixes which start with 
an underscore. Is this convention or a requirement?

3. In Section 3.1 you say "Consumers of the provider services need to relay 
information from a provider's website to their local DNS administrators". There 
are other ways to relay the information from provider to consumer, such as 
S/MIME, and the specification should reflect this.

4. Section 3.1 states "Providers MUST provide clear instructions on when a 
verifying record can be removed" and A.1.4 has "The service provider doing the 
verification should specify how long the verification will take". In my 
experience, the most variable part of the process is at the consumer end, 
because the person wishing to use the service is not typically the DNS admin. 
An expiry set solely by the provider doesn't take that variability into 
account. Maybe it's better for the provider to signal a period after which the 
verification would be assumed unsuccesful, and to provide guidance to the 
provider not to make this period too short.

5. My employer's method currently requires the registrant to set a TXT record 
on the apex domain. Thank you for providing 2 reasons in A.1.1 why we should 
not.

Regards,
Alex

—
Alex Stuart (he/him)
Trust and Identity technical architect
alex.stu...@jisc.ac.uk










Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under company number. 05747339, VAT 
number GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane, Bristol, 
BS1 6NB. T 0203 697 5800.


Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited 
by guarantee which is registered in England under company number 02881024, VAT 
number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 
6NB. T 0203 697 5800.


Jisc Commercial Limited is a wholly owned Jisc subsidiary and a company limited 
by shares which is registered in England under company number 09316933, VAT 
number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 
6NB. T 0203 697 5800.


For more details on how Jisc handles your data see our privacy notice here: 
https://www.jisc.ac.uk/website/privacy-notice
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated: Compact Denial of Existence

[Christian Elmerot]

On 2023-03-28 06:41, Shumon Huque wrote:
On Tue, Mar 28, 2023 at 10:01 AM Viktor Dukhovni 
 wrote:


[ Multi-response to four upthread messages. ]

---

On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote:

> Thanks for your comments. We've posted an updated draft (-01):
>
>
https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01

[ Copied from today's dns-operations post on the same general topic. ]

A possibly inconvenient question, just to make sure we're not ignoring
the obvious sceptical position:

* How compelling is compact DoE?

The reason to ask is that both the original and now modified protocols
involve non-trivial complexity, and would likely require resolvers to
respond differently to queries with the DO bit set (pass them the
NODATA
"truth" along with the NXNAME signal) vs. queries that don't request
validated answers (pass them the inferred NXDOMAIN).

The savings vs. actual by-the-book NSEC responses appear to be a 2x
reduction in the number of signatures to compute (the SOA RRSIG is
presumably easily cached) and a 1.5x reduction in the number of
signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC).

Do the CPU and packet size reductions justify the additional protocol
complexity?


I'll also regurgitate my message here from the dns-operations@ list 
thread:


That's a reasonable question, and perhaps best directed to the 
originators of the scheme at Cloudflare. I don't know if there have 
been any measurement studies or analyses of the cost benefits vs 
by-the-book DNSSEC. There are currently 3 large commercial DNS 
providers that have had it deployed for a while now, so I suspect that 
it is here to stay.


Compact DoE should be seen through the lens of online signing and that 
changes the perspective quite a bit for large providers. That the answer 
is compact is a clear benefit but reducing the amount of work the 
authoritative server has to perform is more important. The server does 
not need to know the contents of the full zone, just that either the 
name or the type in question does not exists. No need to lookup closest 
enclosers etc. Depending on how you've designed the internals of your 
server this reduction in the work you have to perform is likely 
substantial. The proposal for Compact DoE is also of benefit to 
validating resolvers for normal workloads as less signatures have to be 
validated. On the flip side there is the question of a random prefix 
attacks and RFC 8198,  but then again "white-lies" and NSEC3 opt-out was 
kind of the needle to that balloon so this (Compact DoE) is not making 
that situation any worse.


/Christian___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Genart last call review of draft-ietf-dnsop-alt-tld-22

[Behcet Sarikaya via Datatracker]

Reviewer: Behcet Sarikaya
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-alt-tld-??
Reviewer: Behcet Sarikaya
Review Date: 2023-03-28
IETF LC End Date: 2023-04-10
IESG Telechat date: Not scheduled for a telechat

Summary:Ready

Major issues:None

Minor issues:None

Nits/editorial comments:
a) I managed to find in this well written document one typo:

Section 6

we would like to
   sincerely apolgized for anyone who we forgot to credit

apologize
b) Lack of an example .alt TLD as indicated in the Artart LC Review. I wonder
if this is due to maybe there will be none.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated: Compact Denial of Existence

[Paul Vixie]

see inline.

Viktor Dukhovni wrote on 2023-03-27 18:00:

[ Multi-response to four upthread messages. ]

---

...

A possibly inconvenient question, just to make sure we're not ignoring
the obvious sceptical position:

* How compelling is compact DoE?


that may depend on the beholder's eye. for perspective, no root name 
server has deployed this alternative form of Denial of Existence, and i 
believe this includes the f-root anycast instances operated by 
cloudflare under ISC's management. root name servers receive an awful 
lot of junk, and aren't in general overfunded, so if compactness of DoE 
was compelling for anybody, it seems like it would be for them. yet:



; <<>> DiG 9.18.9 <<>> +dnssec luasfluh. @f.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55686
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;luasfluh.  IN  A

;; AUTHORITY SECTION:
.   86400   IN  SOA a.root-servers.net. 
nstld.verisign-grs.com. 2023032800 1800 900 604800 86400
.   86400   IN  RRSIG   SOA 8 0 86400 2023041005 
2023032804 951 . lNcrq1jIeyKGIpkcgMdpPW77yeCLJ+2vU9+HM9Jwr0m1g6RZE8YyxlRA 
+q2oIuDHailclFDPMdjgX2lAMhxaNjWl/H+c2fjZN4+yIRWDcUPnDou5 
sn0S5s2fZQTqdnVghSz4JVXJUCo6bTPWDoA8kt/kuXL/bamISWiI0P39 
VYplvnIVVm7/oQ8gYmWChNfl3TkCXZsbLtsKc2sW5Ssjb50Gs7WKduvo 
UCJRmviRNfJvWcZt1nzZWNGTlwDQcJKTLQDSdXXQd+j4FyUpgIAS3THd 
GzpQblEEKSgYRrGUGbZJ9QKAy0niI2D0JVqHmeHP+g3M8CC7QKKK3FsH Xb9Paw==
lu. 86400   IN  NSEClundbeck. NS DS RRSIG NSEC
lu. 86400   IN  RRSIG   NSEC 8 1 86400 2023041005 
2023032804 951 . KS2/AAlD6atD3EfuRwCciYyBtl4aedoOMd2Z60EzZFoXbbGm9ghYPFeB 
xO+7MpYUTeNQ8ZSI9hZXeNf5ood3QORw4Wevo+XxoQoFnHxyXnLjlpXA 
2h+N3/yPjt20iCTD6zF1n/AOxDnATzIabj6StaMO4dMD7pXTHQxWE+a5 
vCQNRrWVQKv43QFj7zkEBaYX7YHFwKyODdIXnIBnrq1sItGqpZ8nYoaZ 
odCGzFyaMh3vN1FPbrgVhTDeDFFAkQ8k9nZjmQ+r6YtZqgdsx9zY5Lao 
K/EfL6+2UtGiQSVi1O/KzxjZ933t0BkyFNv6jqZANNfTIt1PBvbFWDH+ jfiCbw==
.   86400   IN  NSECaaa. NS SOA RRSIG NSEC DNSKEY
.   86400   IN  RRSIG   NSEC 8 0 86400 2023041005 
2023032804 951 . s9mtWsArs0D1e93ri9e7FVsvMH8gQE/R2zO2plcvd+gkbNuuQwR+SyYT 
rJu7s0mUkuKCsNyU26k8E4ve5S7RbI7Zkg5mGVUoaoLOlk229l3PGPzj 
pj1k8fyHUh1ed1PyYxq1UlnIxPAGiSCocKHlB5Dp1CHACCw4zYT4bl/V 
czCCcyqesCD+eTI+CF1hMiZOOIc9heViHENFzG1qPCH8PLDHJVpl3cJm 
H0zriGwGQk8D/JGp2M7SEgr/JmJCSpmHwmMbwC//UUaPKvpFLqoEFr5x 
6TCxDDg5u8eynptBeuoRqKYBWey+nl1pAC30tBhkjwqCjS19fNBVhmbh BbygbA==

;; Query time: 3 msec
;; SERVER: 2001:500:2f::f#53(f.root-servers.net) (UDP)
;; WHEN: Tue Mar 28 12:42:04 UTC 2023
;; MSG SIZE  rcvd: 1028


i strongly suspect that the era has passed during which compactness of 
DoE was worth its complexity cost. however, i think that's a decision 
for each operator. my only objective concern is that all Denial of 
Existence signals emitted by any DNS server be distinguishable from 
NODATA and distinguishable from ENT. so if "compact DoE" goes forward 
those should be hard requirements.



The reason to ask is that both the original and now modified protocols
involve non-trivial complexity, and would likely require resolvers to
... 
i feel you, brother. however, if operators insist that they've got to 
have this, we'll have to accept the complexity costs necessary to meet 
my above-described hard requirements.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Matthew Pounsett]

On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:

>
>
> On 3/28/23 03:14, Shumon Huque wrote:
> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni  > wrote:
> >
> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > Can we at least state that domains with cyclic dependencies are a bad
> > idea, and may not be supported by all resolvers.  In other words,
> that
> > the domain owner can't **rely** on the sibling glue recommended to be
> > sent in this draft to save the day.
> >
> > My strong preference is still to delete all reference in the draft to
> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> > sibling glue primarily as a performance optimisation, and secondarily
> > as a last resort when the nameserver IP addresses are wrong or gone
> > from the authoritative zone (another bad practice).
> >
> >
> > Viktor - I've so far not seen many other people speak up in support of
> your
> > position. I suspect this is because this draft was discussed to death
> many
> > months ago during long discussion threads on the list, and there is
> likely
> > already rough consensus for the current content. Personally, I would be
> ok
> > with adding a statement that configurations involving cyclic dependencies
> > are not recommended, but others will likely have to also speak up in
> support
> > of this too.
>
> I support adding such a statement about cyclic dependencies.
>

As do I.


>
> In addition, I would support saying that data suggests that, while
> (non-cyclic) glue records may have a benefit in certain cases, they
> frequently are a source of harm (time-outs), and the trade-off remains
> unclear.
>

I would support this as well.

In my anecdotal experience as an operator, I routinely encounter mismatches
in sibling glue and child zone NS sets that appear to be due to the glue
being forgotten.  My assumption is that, because it's not necessary to
operate, when operators fail to update it they don't receive any kind of
signal that something is wrong.

Viktor's numbers are pretty clear data, though, so nobody should need my
anecdotes to be convinced.  While sibling glue may be a useful optimisation
in some cases, given how poorly maintained it is it seems to cause more
problems than it solves.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Peter Thomassen]

On 3/28/23 03:14, Shumon Huque wrote:

On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni mailto:ietf-d...@dukhovni.org>> wrote:

On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
Can we at least state that domains with cyclic dependencies are a bad
idea, and may not be supported by all resolvers.  In other words, that
the domain owner can't **rely** on the sibling glue recommended to be
sent in this draft to save the day.

My strong preference is still to delete all reference in the draft to
cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
sibling glue primarily as a performance optimisation, and secondarily
as a last resort when the nameserver IP addresses are wrong or gone
from the authoritative zone (another bad practice).


Viktor - I've so far not seen many other people speak up in support of your
position. I suspect this is because this draft was discussed to death many
months ago during long discussion threads on the list, and there is likely
already rough consensus for the current content. Personally, I would be ok
with adding a statement that configurations involving cyclic dependencies
are not recommended, but others will likely have to also speak up in support
of this too.


I support adding such a statement about cyclic dependencies.

In addition, I would support saying that data suggests that, while (non-cyclic) 
glue records may have a benefit in certain cases, they frequently are a source 
of harm (time-outs), and the trade-off remains unclear.

FWIW, I hold this opinion because I find Viktor's numbers pretty convincing. 
However, as I've never operated a resolver, I'm convinced solely based on what 
I've read (to the best of my ability), not based on what I've experienced. 
Others' first-hand experience may be more material.

~Peter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop