Subject: Re: [DNSOP] A new appoarch for identifying anycast name server instance

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 Sep 2011 13:46:02 +0900

I'm forwarding a mail from Xun as he mistakenly send it not to
the list but to me.

					Masataka Ohta

-------- Original Message --------
Quoting Masataka Ohta <[email-masked]>:

> [email-masked] wrote:
> 
> > One result of that work is that we think additional information
> > would make anycast dianosis much easier---
> 
> How can it be made much easier?
> 
> All the anycast servers should have unicast addresses to be
> used for zone transfer, which can be used for most, if not all,
> diagnostics.
> 
> So, what diagnosis, are you considering, becomes possible
> only by your proposal?

I think the initial e-mail text we sent is short and incomplete,
our draft proposal is clearer.

The particular diagnostic that our
proposal tries to provide is to tell which one of a set of
anycast servers responses to a DNS query. Unicast address of an
anycast server is very useful for many diagnostics, however, as
DNS queries is sent to the anycast address and the path is decided
by routing system, knowing the set of unicast address may not
sufficient to answer that question.

For the diagnosis that becomes possible ONLY by our proposal,
to our knowledge, is the identification of anycast nodes in
catchments other than where the querier is currently located.
One example utility might be to tell which authoritative name
server provides answers to a recursive name server.

> 
> Also, I'm afraid a fantastic idea of "anycast node" of
> RFC4892 is a result of broken specification of IPv6 anycast
> (yes, IPv6 is broken in several ways), which assumes there
> should be more than one anycast servers sharing an anycast
> address on a link. Anyway, we can't discuss anything
> meaningful about "anycast node", because its definition
> is too fuzzy.

I am not sure if I correctly understand your statement. Did
you mean multiple anycast servers sharing a same path is only
for IPv6? If so, I don't agree. We know that at least F root
has multiple anycast servers in a site (which we think has
same meaning to RFC4786 defined "anycast node") for
address 192.5.5.241. And I believe a load-balancing mechanism
is reasonable for anycasted authoritative name servers. So
"anycast node" should not be discarded at this time.

> 
> As the terminology is very confusing with "node" of domain
> tree and "node" of IPv6, the entire idea of "anycast node"
> should better be silently ignored.
> 
> 						Masataka Ohta
>

---

From: [email-masked]
Date: Mon, 26 Sep 2011 22:34:18 -0700

Thank you very much, Masataka! 

Quoting Masataka Ohta <[email-masked]>:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 Sep 2011 18:49:03 +0900

> anycast servers responses to a DNS query.

It's a reception by a hospital clerk rather than a diagnosis
by a doctor, I'm afraid.

> Unicast address of an

That is an issue better handled by IP layer.

> for IPv6?

I'm not sure either, because of broken terminology of the RFC,
which is your problem.

Are you saying "anycast node" is, following a definition of
"node" of IPv6, something looks like a server for the rest
of the Internet?

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Sep 2011 13:33:07 +0000

> That is an issue better handled by IP layer.

The purpose I see in this proposal, that cannot be handled by the IP layer, is 
to tell me which anycast instance is seen by some recursive name server.  All 
our current diagnostics rely on contacting the server itself to see which 
server answers us.  The proposal now being discussed allows the DNS control 
plane to be tested.

In other words if I want to know which F-root instance I am being routed to, I 
can ask, "dig @f.root-servers.net version.bind ch txt" or the equivilent in 
terms of "id.server".  But if i want to know which F-root node my ISP's name 
server is being routed to, I have no tools available today.  I would like to 
be able to say "dig @75.75.75.75 _hostname._ns_diags.f.root-servers.net txt" 
or similar.  To do that, there has to be an NS record at or below the name 
server name (or some other predictable rendezvous point in the naming system) 
and each instance must serve that zone locally with localized content.

I support the general concept of this draft.

re: http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt

Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Sep 2011 13:33:07 +0000

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 Sep 2011 22:51:09 +0900

> server answers us.  The proposal now being discussed allows the DNS control

Are you saying that end users, not name server operators, diagnose
anycasted name servers?

Certainly, you, as an end user, can do so.

Moreover, your report as an end user to name server operators may
not be ignored, if you can somehow bypass call center operators
to reach someone who knows what BIND means.

In general, however...

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Sep 2011 00:51:10 +0000

On Tue, 27 Sep 2011 22:51:09 +0900
Masataka Ohta <[email-masked]> wrote:

> Paul Vixie wrote:
> 
> > The purpose I see in this proposal, that cannot be handled by the
> > IP layer, is to tell me which anycast instance is seen by some
> > recursive name server.  All our current diagnostics rely on
> > contacting the server itself to see which server answers us.  The
> > proposal now being discussed allows the DNS control plane to be
> > tested.
> 

no.

> Certainly, you, as an end user, can do so.

i think i could diagnose problems reported on my authority server if
i could get a recursive name server to tell me which of my anycast
instances it is talking to.

there may also be some network mapping and measurement benefits to this
proposal.
-- 
Paul Vixie

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 Sep 2011 16:34:55 +0900

> instances it is talking to.

The problem is that the report is unreliable. As your assumption
is:

> The purpose I see in this proposal, that cannot be handled by
> the IP layer, is to tell me which anycast instance is seen
> by some recursive name server.

even you can't diagnose the problem, if what is broken is not
your server but the recursive name server used by someone who
reported the problem and you can't have access to the recursive
name server.

BTW, IP layer solution could be a recommendation on anycast
servers to use their unicast addresses as source addresses
of ICMP replies, which may be able to traverse NAT.

> there may also be some network mapping and measurement benefits
> to this proposal.

May or may not be.

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Sep 2011 09:47:37 +0000

On Thursday, September 29, 2011 07:34:55 am Masataka Ohta wrote:
> The problem is that the report is unreliable. As your assumption is:

that happens sometimes.  however, i often end up in an email conversation with 
a problem reporter, and i often ask them to run certain "dig" commands.  so, 
even if i can't reach a recursive server, a feature like this can still help 
me.

> > there may also be some network mapping and measurement benefits

there are ~16M open recursive name servers right now.  so, i say, "may".

---

From: "William F. Maton" <[email-masked]>
Date: Thu, 29 Sep 2011 06:09:54 -0400 (EDT)

> even if i can't reach a recursive server, a feature like this can still help

+1

> there are ~16M open recursive name servers right now.  so, i say, "may".

In lieu of remote looking glass equivalents for DNS, open recursive name 
servers have unwittingly helped me gain an idea (if not a precise one) 
of where the target anycast servers are located.  The more open recursive 
name servers there are to test, the better I can triangulate.  So yes, 
this proposal may be useful on that score.

wfms

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 Sep 2011 20:05:17 +0900

> even if i can't reach a recursive server, a feature like this can still help

It may work for you if you don't receive too much wrong requests.

For scalable management, however, what you need is call center
operators as a firewall.

> there are ~16M open recursive name servers right now.  so, i say, "may".

But, information on them is easily obtained by anycast servers.

Or, are you mentioning huge scale network mapping and measurements
on zillions of clients behind ~16M servers?

						Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 29 Sep 2011 07:19:22 -0700

> For scalable management, however, what you need is call center

And we're already seeing today, and expect more in the future, systems where the front-line support instructions include "run a one-click or two-click tool", rather than "run dig".

As an author of such tools, I strongly support this proposal, as the basic philosophy of these tools are:

1:  Discover a common problem

2:  Develop a manual test that understands that problem

{this is the "ask the user to run dig" method.}

3:  Wrap up an automatic version of the test into the comprehensive suite...

We have already seen that 3 is very powerful with Netalyzr: at least one on-line game has adopted Netalyzr as their debugging tool of choice for more advanced problems.

The information that this proposal realizes, through the use of a very simple convention, would be of an aid in debugging subtle anycast problems, over paths that the user OR anycast operator can't easily access otherwise.  

Yes, the end USER probably doesn't, and shouldn't care about such information, but it must be obtainable from the end user's vantage point if you want to enable such tools to debug DNS anycast issues.

The only additions I'd make is an additional keywords medium- and long- prepended to the query, and unicast-ip.  

The length keyword should have the same information, but with padding in the text records to a packet length of approximately 1100B and 1800B long.

The reason for this addition is to enable debugging of individual paths for DNS MTU issues.

While unicast-ip should return an A record for (a) unicast IP address of the server.

The reason for this is to assist tools which can look up A records but not TXT records.  (EG, the Java API allows easy lookup of IP addresses but doesn't allow grabbing of TXT records, so unless the Java applet is contacting the server directly, server identification can be harder).

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 Sep 2011 23:40:27 +0900

Nicholas Weaver wrote:

> And we're already seeing today, and expect more in the future,
> systems where the front-line support instructions include
> "run a one-click or two-click tool", rather than "run dig".

It means those who can use "run a one-click or two-click tool"
have no idea on how to bypass intermediate entities, which
means call center operators as a firewall is definitely
necessary.

> As an author of such tools, I strongly support this proposal,
> as the basic philosophy of these tools are:

As I said, the basic philosophy is do it at the IP layer.

How, do you think, about ICMP reply I mentioned, which is, in
theory, required by RFC1122?

						Masataka Ohta

PS

Before developing tools, you should better learn to wrap
your lines well below 72 characters.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 29 Sep 2011 08:36:26 -0700

> means call center operators as a firewall is definitely

I think you're missing something subtle here, both in this comment and in the "Do it in IP layer" comment.

Well constructed tools like Netalyzr are able to infer properties about paths that they don't have direct access to, based on how traffic is passed through them: making sure that the traffic will reveal desired information.

This proposal allows debuging information about the "recursive resolver TO anycast authority" path, a path which the user AND anycast operator do not otherwise have direct access to.  Only the recursive resolver operator has access to that path, and for much debugging, the recursive resolver OPERATOR is not a participant in the process.

And the end user running the tool, combined with the tech support person on the other end who sees the results, CAN often bypass the broken intermediate entitites, depending on what the results are that the tool spits out:

a:  If its their NAT or local CPE being very lame: blocking requests AND with a bad proxy, tell the user to replace it.

b:  If the CPE is giving its own lame proxy but can be bypassed, instruct the user how to use Google Public DNS: problem solved for the user without needing a forklift upgrade.

c:  If the recursive resolver itself is being lame (eg, how Earthlink's was the other day), either instruct the user how to bypass it, OR start applying various pressures to the resolver operator to get it fixed ASAP.

d:  If its a path problem between the recursive resolver and the authority, tech support escalates it internally.

a, b, and c you can get today with some care (we don't package it up in Netalyzr, but we can distinguish between the three cases in the data), but D is hard, and this requires tools such as the proposal.

> your lines well below 72 characters.

That your mail reader can't word wrap properly on received messages is not my problem.  

Word wrapping MUST be done on the recipient side, not on the sender side, unless you want to maintain ridiculous conventions like "text lines are at most 72 characters, monospaced" which were obsolete two decades ago.

And in this case particular case, blame Microsoft.

Apple on their mailer for the longest time implemented a standard method, format=flowed, intended to please BOTH mail readers that can word-wrap and mail readers that can't.  But they dropped this way back in 10.6.2, because Microsoft never recognized it right.

Given the choice between pleasing a few recipients who cling to an obsolete convention with obsolete tools and pleasing the very large population of recipients with a tool unwilling to accept a standard which could please both, Apple went with the natural choice: it is the mail reader's responsibility to word wrap to the reader's own display parameters.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 30 Sep 2011 01:34:24 +0900

> I think you're missing something subtle here, both in this comment and in the "Do it in IP layer" comment.

I'm afraid it's you.

> This proposal allows debuging information about the "recursive
resolver TO anycast authority" path, a path which the user
AND anycast operator do not otherwise have direct access to.

As for subtlety, what if, the information is cached and stale?

OTOH, identification by ICMP is up to date save RTT.

I skipped to read rest of your mail, because you have not learned
to wrap lines properly.

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Sep 2011 17:11:56 +0000

On Thursday, September 29, 2011 03:36:26 pm Nicholas Weaver wrote:
> Word wrapping MUST be done on the recipient side, not on the sender side,
> unless you want to maintain ridiculous conventions like "text lines are at
> most 72 characters, monospaced" which were obsolete two decades ago.
> 
> Apple on their mailer for the longest time implemented a standard method,
> format=flowed, intended to please BOTH mail readers that can word-wrap and
> mail readers that can't.  But they dropped this way back in 10.6.2,
> because Microsoft never recognized it right.
> 
> Given the choice between pleasing a few recipients who cling to an obsolete
> convention with obsolete tools and pleasing the very large population of
> recipients with a tool unwilling to accept a standard which could please
> both, Apple went with the natural choice: it is the mail reader's
> responsibility to word wrap to the reader's own display parameters.

format=flowed gave the nec'y hint, told my user agent that the text was meant 
to be wrapped.  in the absence of this hint, i don't get word wrapping because 
the columns might be fixed.  (like code fragments or similar.)  so i do blame 
microsoft for not doing the right thing with format=flowed, but i also blame 
apple for going off-rails and violating the principle of least astonishment 
for an unknown but nonshrinking population of non-microsoft e-mail readers.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 29 Sep 2011 10:12:38 -0700

Note:  The following is manually formatted because
you are incapable of using a modern mail reader OR
have deliberately misconfigured your modern mail reader
OR are reading the message using a buggy archive:

> As for subtlety, what if, the information is cached and stale?

Good point, but there are easy solutions:

a:  Do you honestly expect these queries to be common enough 
to be cached?

b:  These should have a TTL of 0 seconds and/or support a 
prepended, cache-busting wildcard.

> OTOH, identification by ICMP is up to date save RTT.

How can one generate an ICMP on the path from the resolver's
outbound interface to  to the authority, and receive the 
response, without access to the resolver?

Please tell me how to do so, in a way that is expected
to work, so I can use this in automating some significant 
problem solving.

> I skipped to read rest of your mail, because you have not learned

Your inability to use a modern mail client is NOT MY PROBLEM!

Let me reiterate, manually formatted to please you: 

That your mail reader can't word wrap properly on 
received messages is not my problem. 

Word wrapping MUST be done on the recipient side, 
not on the sender side, unless you want to maintain 
ridiculous conventions like "text lines are at most 72 
characters, monospaced" which were obsolete two 
decades ago.

Apple on their mailer for the longest time implemented 
a standard method, format=flowed, intended to please 
BOTH mail readers that can word-wrap and mail readers 
that can't.  But they dropped this way back in 10.6.2, 
because Microsoft never recognized it right.

Given the choice between pleasing a few recipients who 
cling to an obsolete convention with obsolete tools and 
pleasing the very large population of recipients with 
a tool unwilling to accept a standard which could please 
both, Apple went with the natural choice: it is the mail
reader's responsibility to word wrap to the reader's 
own display parameters.

As an addition, your headers suggest you are using
Thunderbird.  I checked Thunderbird 6 on OS-X this morning,
it word wraps unstructured text flawlessly.  Please ensure
that you haven't mistakenly turned on a mis-formatting 
"feature".

If you are complaining because a particular web mail 
archive you are using are not formatting properly, it 
is a bug in the archive generation tool's HTML 
formatting, and should be reported as such.

---

From: Alex Nicoll <[email-masked]>
Date: Thu, 29 Sep 2011 13:59:36 -0400

You know Nicholas, if you've got time to respond to the next best thing [DNSOP] and [DNSEXT] have to a troll, we still need a replacement mechanism for registering EDNS0 types. :)

For you curmudgeons like me, remember to "Meta-x auto-fill-mode" before you read this note.

o.b.DNS:  If I use both SPF and DKIM, do I get SPDIF for better DNS surround sound?

-Alex

(Note:  I don't know, and I don't care, if 'taka does it intentionally.  Just a trend I've noticed.  This is all just my completely subjective opinion, and should be disregarded as such.)  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicholas Weaver
Sent: Thursday, September 29, 2011 1:13 PM
To: Masataka Ohta
Cc: Paul Vixie; [email-masked]; Nicholas Weaver
Subject: Re: [DNSOP] A new appoarch for identifying anycast name server instance

Note:  The following is manually formatted because you are incapable of using a modern mail reader OR have deliberately misconfigured your modern mail reader OR are reading the message using a buggy archive:

On Sep 29, 2011, at 9:34 AM, Masataka Ohta wrote:

> resolver TO anycast authority" path, a path which the user AND anycast 
> operator do not otherwise have direct access to.
> 

a:  Do you honestly expect these queries to be common enough to be cached?

b:  These should have a TTL of 0 seconds and/or support a prepended, cache-busting wildcard.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 30 Sep 2011 17:04:32 +0900

> Note:  The following is manually formatted because

because you choose not to use a feature of modern mail
composers?

> Good point, but there are easy solutions:

You are still missing the subtlety.

> a:  Do you honestly expect these queries to be common enough

That's no solution.

> prepended, cache-busting wildcard.

Loss of synchronization can occur between cached normal data
and uncached identification data. And, as I already mentioned
what is broken may be the caching server.

> response, without access to the resolver?

Ask one's resolver operator to do so. He will investigate
what's wrong and may contact an anycast server operator
if he think there is a real problem for which his resolver
is not responsible.

As Paul Vixie can not accept all the reports from all the end
users, aggregation through resolver operator path is the way
for scalable operation.

> received messages is not my problem.

See my first lines of this mail.

> characters, monospaced" which were obsolete two

72 (actually 80 or 132, but we should be conservative)
characters is based on ergonomics of key board size
and legible character size, which have had and will have
longer history than Apple.

See this thread in IETF ML this February for further enlightment:

https://www.ietf.org/ibin/c5i?mid=6&rid=48&gid=0&k1=933&k3=9861&tid=1317368971

> that can't.  But they dropped this way back in 10.6.2,

That you don't accept that reality is your problem.

> that you haven't mistakenly turned on a mis-formatting

I use my mail readers with my own configuration both for
English and Japanese (where ASCII space characters are
basically not used) mails.

					Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 30 Sep 2011 06:22:46 -0700

> what is broken may be the caching server.

Correct.  But this is why you need to have queries that check the
caching server AS WELL.  The CHAOS queries are useful here, as
are queries for the cached normal data, and queries which infer
glue policy so you can know if/what the cached normal data is being
used.

> if he think there is a real problem for which his resolver

How am I, in building an automated tool designed to diagnose
as many problems as possible, supposed to ask a HUMAN at
A SEPARATE SITE to conduct MANUAL queries on my tool's behalf?

?????

The major use I see for these queries is in automatic debugging, 
not human intervention, to understand if there is a problem which
will require human intervention.

Your "IP layer" solution only works for human intervention, and
only starting with humans which aren't initially in the debugging
process.

> users, aggregation through resolver operator path is the way

But until you can generate queries to test the path how are
you supposed to know where to start looking for the problem?

As a builder of tools, I need to be able to test all the paths
I possibly can that might affects a user's traffic.  Direct when 
possible, and by inference through queries this this when not.

EG, I already have tests that can determine whether it is the recursive 
resolver which has problems with fragmentations or large responses.  

Yes, from the client standpoint this limits the fixes that can be 
applied, but automated tools on the client need to know this 
information in order to know how to react to the problem.

(If I wanted to, I could even identify the hop for the firewall on the
resolver that has this problem, but I don't want to build that test,
because I'm lazy and its sufficient to know "its the resolver that
is broken" for my current purposes)

This is similar information:  Information a CLIENT can use to
ATTEMPT to diagnose problems elsewhere in the network by inference.
It may not be perfect, but it will tell the client enough to know
who to talk to.

EG in your criticism, it could be the resolver, not the path
between the resolver and authority thats broken.  But even that
is useful information, AND additional queries may help, eg, what
is the TTL on the cached information the resolver is returning
when you query it?

The Old Fashoned Mail Reader Flame War below:  Everyone else
just stop reading now and save your eyeballs.

I'm including it so it is on the record, but its below so everyone
else can ignore it.

> basically not used) mails.

You have  deliberately misconfigured your tool to ignore critical
formatting information for ASCII text.

My suggestion is to reinclude spaces, but have the spaces be
in a much smaller font.  Your on-screen presentation should
be the same, but it is likely that your displayer will
break on the mini-spaces, providing a word-wrap to your
desired window width.

Also, note that Format=flowed causes more problems than it solves

a)  It messes up presentation on a much LARGER population of
mail clients.

b)  It incorrectly modifies formatting!  You can not properly cut and
paste blocks of code or other items into mail messages, as it ends up
destroying the real formatting.

c)  Format=flowed is NOT required.  It is an optional feature that
only some mail composers bother with.  Notably the biggest clients
DO NOT send it that way:

Outlook neither sends nor receives it properly to my knowledge.  So
sending such email breaks a HUGE number of clients.

Mac mail receives it properly but does not send it after concluding
that it was breaking more than it was fixing.

Gmail's web client does not send it, instead mangling plain text
to 72 columns by default.  This is even worse: their "solution"
will ensure that not only will the text not display wide when
the user is on a wide device, but that it will display badly and
narrow when the user is on a device like a smartphone.

"Standards" which 90%+ of the market have rejected are not standards,
but wishful thinking.

---

From: Stephen Morris <[email-masked]>
Date: Fri, 30 Sep 2011 15:00:11 +0100

On 30/09/2011 14:22, Nicholas Weaver wrote:
> The Old Fashoned Mail Reader Flame War below:  Everyone else just 
> stop reading now and save your eyeballs.

By all means carry on with the discussion of the identification of
anycast nameserver instances, but Mail Reader Flame Wars are not in
the scope of DNSOP and should not be carried out on this list.

Thanks,

Stephen
DNSOP Co-Chair

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 01 Oct 2011 09:56:49 +0900

> glue policy so you can know if/what the cached normal data is being

Don't solve a simple problem in such a complex way.

> as many problems as possible,

That's your fundamental misunderstanding.

Professionals use simple tools. That's the only way to solve
complex, beyond tool builder's imagination, problems in the
real world.

> you supposed to know where to start looking for the problem?

First, login to the caching server. Rest depends on internal
details of the server. There may be some tools available
on the server.

> The Old Fashoned Mail Reader Flame War below:

I think I gave you a pointer to a thread in IETF ML. Feel free
to reopen it there but not here.

						Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 30 Sep 2011 18:32:41 -0700

> Don't solve a simple problem in such a complex way.

If it can affect users, it should be testable from the user's system if possible.

> complex, beyond tool builder's imagination, problems in the

No, professional tool-builders benefit from building a full rich suite of tools which combine many tests.  And, if done right, become favorite tools of professionals as well as amateurs.  [1]

Each test, on its own, can be done "as a simple tool": eg, "Whats the exact DNS PMTU for the authority to resolver path"?  You would be welcome to build a special command-line client to do so.  

But in the end, you really do have to test as many things as possible, in as automatic a way as possible if you want to

a:  Find out what problems an arbitrary end user is facing.   E.G.  "Your Mother is complaining about her Internet connection."  Do you really want to walk her through a set of 60+ separate tests in the debugging flow?

or

b:  Make the network fix itself.

> details of the server. There may be some tools available

Your attitude seems to be: "This is ONLY a problem from the point of view of the resolver operator".

I disagree.

For all multicasted authorities who don't have your attitude, this seems a very simple and easy convention: it costs a trivial amount of effort, and may be quite useful.  There's no new RTYPEs and no new major changes, just a few records customized for each instance by a startup script.

Those multicast authorities which take your viewpoint can ignore it.

[1] Note on Netalyzr: we do do requests.  E.G. we're looking at adding tests for Olafur's child-sticky problem, and tests for induced stickiness, and have added in port filtering tests to address specific VPN tools used by colleagues.  

So if you want us to roll in additional tests, we do consider it, for all those who actually find a multi-function tool a useful service.