Re: [DNSOP] Updated: Compact Denial of Existence

[Mark Andrews]

> On 6 Mar 2023, at 04:20, Peter Thomassen  wrote:
> 
> 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL 
> type). So far it only has meaning for "type covered" fields in signature 
> records such as SIG(0) (RFC 2931). There appears to be no collision with 
> usage in the NSEC type bitmap, and IMHO it appears to be a very natural meta 
> type fit. ("This is NULL, There Really Is Nothing Underneath.")

NULL is type 10.  This was assigned in RFC 1035.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick

[Peter Thomassen]

Hi Benno, all,

I just went over the updated wording in draft-ietf-dnsop-rfc8499bis-05, and the 
paragraph 
https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8499bis-05.html#section-7-2.36
 caught my attention.

It uses the term "zone origin", but doesn't say whether it relates to the 
parent or child zone. I was assuming the child, and it took me a while to make sense of 
it (until I noticed that it must mean the parent).

I'd like to suggest clarifying that paragraph. That brings me to your question 
below:

On 11/25/22 14:38, Benno Overeinder wrote:

Thank you for your input and your suggestion to come up with a more specific terminology for the 
"historical" out-of-bailiwick term.  In the definition of in-domain and sibling domain, 
you suggest using the 0th and 1st order in the definition?  And for out-of-bailiwick use a term 
like "2nd+ order nameservers"?


Pretty much. Here is a version of it that's hopefully better to grasp than my 
previous post, and has examples.

There are various degrees of relationship between a delegation and its
name servers.  The degree depends on where theirdelegation paths from
the root intersect with the delegated zone's delegation path.

To establish the degree of relationship for a given name server, count
how many zone cuts in the delegation path from the root to the zone of
interest are shared by the delegation path of that name server.  This is
a measure of unrelatedness between the zone and its name server, called
"degree ofkinship".

If the degree is 0, then the NS hostname is "in-domain".  For example,
a delegation for "child.example.com" might have an in-domain name server
called "ns.child.example.com".  The name server name has all the zone
cuts from the root that the delegated domain has.

If this number is non-zero, then the delegation path to the name server
name branches off from the zone's delegation path.  The "degree of
kinship" tells you how many zone cuts above the zone of interest this
happens.  For example, a delegation for "child.example.com" in the
"example.com" zone might have a "sibling domain" name server called
"ns.another.example.com", which does not share the final zonecut of
"child.example.com".  The branching is at "example.com", and the degree
of kinship is 1.

An unrelated relationship is one where the degree of kinship is larger
than 1.  For example, the delegation for "example.jp" might have an
name server "ns.example.com".  The delegation paths alreadydiverge at
the root, 2 zone cuts above "example.jp".

This may be a bit verbose, but I'm sure it can be reduced to four paragraphs, 
if needed, that are easier to digest than the four paragraphs the draft 
currently has for these definitions.

While writing the above, I again stumbled over the term "unrelated name server". It could 
mean all kinds of things, such as a name server that doesn't claim to be authoritative. People 
don't always have the definitions at hand, and I think using that term is a risky choice 
(especially as "unrelated" is a word from every-day language).

Best,
Peter

PS: Sorry for digging up this old message (and for not responding earlier; I 
missed it).



I'd love to hear from other DNSOP participants if there is any support for 
Peter or any other suggestions for a good, more specific alternative term for 
out-of-bailiwick?

-- Benno

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


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

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

Re: [DNSOP] Updated: Compact Denial of Existence

[John Levine]

It appears that Peter Thomassen   said:
>> It will require more process work (potentially blocking) to revise other 
>> documents too.
>
>I checked before proposing it, and couldn't find anything that would need 
>revision. RFC 1035 calls that type experimental, no
>NULL RRs allowed in zone file, and content opaque (if used on the wire). To 
>me, that actually looks like a rather ideal set of
>pre-conditions.

RFC 6895 says:

RRTYPE zero is used as a special indicator for the
SIG(0) RR [RFC2931] [RFC4034] and in other
circumstances and must never be allocated for
ordinary use.

I suppose we can have a meta-discussion about whether this is an ordinary use, 
but I would prefer not to.

R's,
John

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

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt

[Wes Hardaker]

Jim Reid  writes:

> Depends on the definition of DNS traffic Ted. DNS-OARC has many TB of
> pcaps and query logs from the DITL project. Whether that data could be
> good enough to meaningfully measure the incidence of QDCOUNT>1 in the
> real world is anyone’s guess.

If it helps, looking at *only* the qdcount field for all traffic
arriving at b.root-servers.net yesterday for any packets where qdcount
was greater than 1 was precisely zero.
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Updated: Compact Denial of Existence

[John Levine]

It appears that Shumon Huque   said:
>2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 ...
>> If I didn't get the math wrong, it would also save 11 bytes in the type
>> bitmap (compared to using the lowest available meta type code, 128),
>> slightly reducing the chance of packet size issues e.g. when double-signing
>> etc.
>>
>
>I'm a bit allergic to re-using an RR type already designated for another
>purpose.

It seems like a poor economy.  If you really are worried about making the
bitmap smaller, I suppose there's unused type 54.  Anyone who's using DNSSEC
is already prepared for large responses so I wouldn't worry about it.

R's,
John

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

Re: [DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

[Warren Kumari]

[ Top-post ]


On Thu, Feb 23, 2023 at 12:39 PM, Warren Kumari  wrote:

> Hi there all,
>
> I was really hoping that it wouldn't come to this, but…
>
>
> We approved draft-ietf-dnsop-svcb-https on 2022-05-22, and has been stuck
> in MISREF state ever since[0], waiting on draft-ietf-tls-esni - "TLS
> Encrypted Client Hello"
>  .  This is
> basically as long as it takes to make a whole person…
>
> There are multiple documents in the RFC Editor queue waiting on the
> svcb-https  document: https://www.rfc-editor.org/cluster_info.php?cid=C461
> .
>
> Unfortunately it now seems that tls-esni is not likely to be published
> anytime soon because they want deployment experience before advancing it,
> and that's not going to happen for some months.
>
> This means that the svcb-https document, and, by extension, the other
> documents in the cluster will be stuck for an indeterminate amount of
> time.
>
> The part of svcb-https  that "needs" tls-esni is sort of an optional
> feature, and none of the other documents in this cluster seem to rely on
> it.
>
> Instead of just having all of these document stuck indefinitely, I'm
> proposing that we:
> 1: Ask the RFC Editor to return the document to the IESG & IETF[1].
> 2: I return it to the WG.
> 3: The authors remove the bits that rely on ESNI
> 4: The document progresses "normally" - it gets another WGLC, IETF LC,
> IESG Eval, etc. Hopefully this can be expedited - it's already gone though
> all of these steps once, and the updated document would be very similar to
> the original.
>

Hi there all,

The RFC Editor is still working on some tooling issues in order to
"officially" return to the document to the IETF/WG, but in the mean time
they have assured me that they will not progress it ("I will work on the
fix now — but rest assured we will not work on this document until it
returns.").

So, consider the document returned to the WG. If the authors can implement
the (already discussed) removal of the ESNI dependency then we can do a
(presumably compressed) WGLC on the changes, an IETF LC, IESG eval and hand
it back to the RFC Editor.

When doing the IETF LC I'll request that people restrict their comments to
just the changes, and the IESG will (presumably) do the same. As this is a
returning item, I'm asking the chairs to please prioritize the WGLC.

W

5: If / when tls-esni is published, the svcb-https authors submit a -bis
> (while will likely just be 'git checkout '), and we
> progress this just like any other WG document.
>
> I've discussed this with the authors of the documents, the DNSOP and TLS
> chairs, the relevant ADs and the full IESG.
>
> However, before doing all this, I'd like to confirm that the WG doesn't
> object to the plan….
>
>
> W
> [0]: Possibly modulo the annoyingly painful "AliasMode clarification"
> change: https://author-tools.ietf.org/
> iddiff?url1=draft-ietf-dnsop-svcb-https-10=draft-ietf-dnsop-svcb-https-11=--html
>
> [1]: While we prefer not do to this sort of thing, we have done it before
> - as an example: https://datatracker.ietf.org/doc/
> draft-ietf-netmod-syslog-model/history/
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9

[Warren Kumari]

Hello authors, chairs and WG,

I was wondering when we'd see an updated version of this document?
The IETF 116 "Internet-Draft submission cut-off" is 2023-03-13 (7 days from
now) - https://datatracker.ietf.org/meeting/116/important-dates/

I think that the requested changes were not particularly major, so
hopefully this can happen soon…


W


On Tue, Jan 24, 2023 at 11:26 AM, Warren Kumari  wrote:

> Hi all,
>
> Thank you to the authors, chairs and WG for wanting to make the document
> as good as it can be, even if that does require some more work.
>
> The chairs have requested that I return it to the WG to get an
> implementation section added, and so I'll do so[0].
>
> Thanks again,
> W
>
> [0]: I'll keep the ballot text, cliffsnotes summary, review notes, etc all
> squirreled away somewhere so that it's easier and faster to progress when
> it returns to me / whoever the next OpsAD is...
>
>
>
>
> On Tue, Jan 24, 2023 at 9:46 AM, Tim Wicinski  wrote:
>
>> The chairs thank all for this feedback, even at this stage.  But it's
>> better to catch these issues now, than
>> later on in the process.
>>
>>
>> On Fri, Jan 20, 2023 at 3:52 PM Ondřej Surý  wrote:
>>
>>> I am indifferent about what label we stick on this, but perhaps the
>>> document should have a section on implementations?
>>>
>>> However, I do feel that the Security Considerations is missing on the
>>> risks of dropping packets, ICMP filtering and dangers of PMTUD.
>>>
>>> Also it feels weird to me that the IP_PMTUDISC_OMIT is used by: BIND 9,
>>> NSD, Unbound, Knot DNS and PowerDNS, but neither the fact nor the reasoning
>>> behind the option is ever mentioned here.
>>>
>>> Hence, I think the Implementors section should be added to the document.
>>
>>
>> an Implementation Section would be useful and generally they appear as an
>> Appendix.
>>
>> Ondrej, if you could suggest some text with what ISC will implement,
>> along with any reasoning, that would be a great start.
>>
>> tim
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
___
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-06 03:35, Shumon Huque wrote:

On Sun, Mar 5, 2023 at 12:20 PM Peter Thomassen  wrote:

Hi,

I like this draft. Some thoughts:

1.) Maybe it's worth pointing out that zones using compact denial
SHOULD (MUST?) use NSEC, not NSEC3.


Yes, we could do that. I agree with Geoff's later point that this 
mechanism could in theory use NSEC3 also. But NSEC is simpler, so 
unless someone has a compelling argument to do NSEC3, I'm fine with 
stating that restriction. All known implementations to date use NSEC.



I'm not opposed to adding the restriction though I'm more in favor of 
adding a mention that using NSEC3 increases complexity and processing 
requirements while providing no additional benefit




2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0
(the NULL type). So far it only has meaning for "type covered"
fields in signature records such as SIG(0) (RFC 2931). There
appears to be no collision with usage in the NSEC type bitmap, and
IMHO it appears to be a very natural meta type fit. ("This is
NULL, There Really Is Nothing Underneath.")

If I didn't get the math wrong, it would also save 11 bytes in the
type bitmap (compared to using the lowest available meta type
code, 128), slightly reducing the chance of packet size issues
e.g. when double-signing etc.


I'm a bit allergic to re-using an RR type already designated for 
another purpose. It will require more process work (potentially 
blocking) to revise other documents too. Also, I've been told by a few 
folks who deal with RR type allocation, that if we standardize this 
mechanism, it will have to be a meta-type.


It's certainly true that using a type in the meta-type range will 
increase the size of the type bitmap some. Your calculation sounds 
right. By comparison, the ENT private type used by NS1 presently 
consumes only 3 more octets (window number 255, 1 byte bitmap). This 
all still seems to be in the noise to me, and perhaps not worth 
worrying about. To your comment about double signing, I suspect the 
bigger concern will be about the computational cost to perform 
multiple cryptographic operations rather than a few extra bytes in the 
signature input. (I've proposed algorithm negotiation mechanisms in 
the past to deal with that, but so far the community hasn't been 
receptive).


[One could ponder defining that NXDOMAIN is indicated with a type
bitmap that has *only* the sentinel in it, or even an empty
bitmap. There would be no information loss, as a validator already
knows about the NSEC (+ RRSIG) record's existence simply by
looking at them; the type map adds nothing at all. The idea is
only semi-serious (because of its risk to cause confusion). I'm
bringing it up only to observe that such an empty bitmap would
require no sentinel type at all!]


I briefly had the same thought, but dismissed it. You will get bogged 
down in long, arduous debates about protocol and cryptographic proof 
correctness. By design, the NSEC record needs to prove its own 
existence. By contrast, the NSEC3 record can't, so can have an empty 
type bitmap (see "The NSEC3 Paradox").


3.) Section 2:

        An alternative way to distinguish NXDOMAIN from ENT is to
define the
        synthetic Resource Record type for ENTs instead, as
specified in
        [ENT-SENTINEL], and this has already been deployed in the
field. This
        typically imposes less work on the server since NXDOMAIN
responses
        are a lot more common than ENTs.

It's likely I'm missing something, but I'm not following. Here's
my line of thinking:

Constructing the NODATA response for a name without data records
requires checking whether the name is an ENT. Depending on the
outcome, a bit is set/unset. How can inverting the condition
affect the amount of work on the server?


I probably didn't explain myself clearly here. It isn't inverting the 
condition. But comparing the work needed to set the distinguisher RR 
type in ENT responses versus setting it in NXDOMAIN responses. Since 
the latter are far more common.


4.) Section 4:

        A signed zone at an authoritative server implementing
Compact Answers
        will never return a response with a response code of NXDOMAIN.

Is this meant literally, or only for queries with "do" flag? 



For responses to queries without "do" flag, there is no DoE
processing. To preserve the DoE information, the return code fur
such responses should IMO continue to be NXDOMAIN.


This isn't defined clearly in the original draft or in this one, and 
we should state explicitly what we want it to be. I believe Cloudflare 
already does what you suggest. But NS1 always returns NODATA, 
regardless of the DO flag.


Yes, for queries without the DO-flag we (Cloudflare) return NXDOMAIN 
RCODE when appropriate.



Note that many modern DNS resolver 

Re: [DNSOP] Updated: Compact Denial of Existence

[Peter Thomassen]

On 3/6/23 03:35, Shumon Huque wrote:

2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL type). So far it 
only has meaning for "type covered" fields in signature records such as SIG(0) (RFC 2931). There 
appears to be no collision with usage in the NSEC type bitmap, and IMHO it appears to be a very natural meta 
type fit. ("This is NULL, There Really Is Nothing Underneath.")

If I didn't get the math wrong, it would also save 11 bytes in the type 
bitmap (compared to using the lowest available meta type code, 128), slightly 
reducing the chance of packet size issues e.g. when double-signing etc.


I'm a bit allergic to re-using an RR type already designated for another 
purpose.


I'm fully with you (= also allergic), but that doesn't mean I'm strictly 
opposed. I think it's fine to use an already assigned rrtype for another 
purpose, if there are good reasons for doing so and there's no risk of 
collision/confusion.


It will require more process work (potentially blocking) to revise other 
documents too.


I checked before proposing it, and couldn't find anything that would need 
revision. RFC 1035 calls that type experimental, no NULL RRs allowed in zone 
file, and content opaque (if used on the wire). To me, that actually looks like 
a rather ideal set of pre-conditions.


Also, I've been told by a few folks who deal with RR type allocation, that if 
we standardize this mechanism, it will have to be a meta-type.


Sure. But I'm not proposing to allocate anything; the NULL type is already allocated. 
Also, I think it is "meta enough", as the type is already specified to not show 
up as the type of an actual record.

I find the natural semantics of "This is NULL, There Really Is Nothing Underneath." 
really appealing, as opposed to "This is 0xFF01, ...".


It's certainly true that using a type in the meta-type range will increase the 
size of the type bitmap some. Your calculation sounds right. By comparison, the 
ENT private type used by NS1 presently consumes only 3 more octets (window 
number 255, 1 byte bitmap).


There's a contradiction of goals here: the meta type values lie entirely in 
window block 0. All of those, except the NULL type, are in the second half of 
the window.


This all still seems to be in the noise to me, and perhaps not worth worrying 
about. To your comment about double signing, I suspect the bigger concern will 
be about the computational cost to perform multiple cryptographic operations 
rather than a few extra bytes in the signature input.


I agree for now, but we don't know the size constraints of the future, such as 
which algorithms one will have to roll to. My take is that barring a technical 
reason to spend 11 bytes, we should pick the more compact data structure unless 
that would cause confusion or an interop problem.

It's unclear whether the 11 bytes will ever be important, and I don't feel 
strongly about it. I find the natural semantic fit much more important.

As you pointed out in a separate message, keeping NXDOMAIN signaling clean and 
healthy is an important concern. Just assume for a moment that Compact DoE with 
NULL type had been around for years. It would feel very clean and almost 
obvious for this signal to live in the first bit of the type map.

This bit is currently unused and happens to have a fitting name already.


For responses to queries without "do" flag, there is no DoE processing. To 
preserve the DoE information, the return code fur such responses should IMO continue to 
be NXDOMAIN.


This isn't defined clearly in the original draft or in this one, and we should 
state explicitly what we want it to be. I believe Cloudflare already does what 
you suggest. But NS1 always returns NODATA, regardless of the DO flag.


Hm, at least the latter I find rather unexpected.


If the return code is not allowed to depend on the "do" flag, it may be better to 
return NXDOMAIN even to "do" queries, in combination with the Compact Denial NSEC record. 
The draft correctly says that it is not authenticated, but retaining it probably wouldn't hurt.


I suspect that unilaterally putting NXDOMAIN into the rcode field will break a 
lot of validator code. They are likely to use the rcode to advise them on what 
type of proof to look for in the message body, and they won't find a 
traditional NXDOMAIN proof. Maybe we can ask resolver implementers on the list 
to speak up about what the actual impact would be for them.


I second the idea of asking them!

Peter

___
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-06 05:00, Paul Vixie wrote:



Peter Thomassen wrote on 2023-03-05 14:56:
(Compact NSEC answers prevent zone enumeration just as well, if not 
better.)


that makes it even cooler, and it was already cool. (so long as the 
nxdomain signal is not suppressed as in the cloudflare prototype.)


We intend to follow the specification. The NXDOMAIN type signal is going 
to be deployed before the end of the month


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

Re: [DNSOP] AD review of draft-ietf-dnsop-alt-tld-21

[Rob Wilton (rwilton)]

Hi Warren, & Paul,

Those proposed changes look fine to me, so please can you post an updated 
version.

Regards,
Rob


From: Warren Kumari 
Sent: 03 March 2023 23:28
To: Rob Wilton (rwilton) 
Cc: dnsop@ietf.org; draft-ietf-dnsop-alt-tld@ietf.org
Subject: Re: AD review of draft-ietf-dnsop-alt-tld-21

On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton 
mailto:rwil...@cisco.com>> wrote:
Hi authors, WG,
Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They are all 
minor/nit comments, meaning that I'll leave it to the authors discretion as to 
how they want to handle these comments.
Minor level comments:
(1) p 3, sec 2. The alt Namespace
Groups wishing to create new alternative namespaces may create their 
alternative namespace under a label that names their namespace under the .alt 
pseudo-TLD. The .alt namespace is unmanaged.
This seems slightly strong given that the ISE draft is planning on setting up a 
registry somewhere. So, perhaps "The .alt namespace is not managed by the IETF 
or IANA"?

Good point.

Here is the original with a bit more text for context:
"The .alt namespace is unmanaged. This document does not define a registry or 
governance model for the .alt namespace."

I don't really know if GNU creating a registry really counts at "managing" the 
.alt namespace, but we can skip that philosophical question by rewording it 
like so:

"This document defines neither a registry nor governance model for the .alt 
namespace, as it is not managed by the IETF or IANA. "


(2) p 3, sec 2. The alt Namespace

This document
does not define a registry or governance model for the .alt namespace. 
Developers, applications and users should not expect unambiguous mappings from 
names to name resolution mechanisms.

Is "Developers, applications, users should not expect unambiguous mappings" a 
bit strong? A possible alternative could be: "Developers, applications and 
users are not guaranteed to have unambiguous mappings from names to name 
resolution mechanisms."

Hmmm - I'm not sure if it is actually a bit strong, I think that the issue is 
more that we cannot really tell developers or users to "expect" anything — my 
auntie might well expect some.name.gns.alt to be an 
unambiguous mapping, and telling her that she shouldn't expect this is silly - 
she doesn't read RFCs[0]

I changed this to "There is no guarantee of unambiguous mappings from names to 
name resolution mechanisms." ? I removed the "Developers, applications and 
users" wording as it just opens the question of who should expect this (cats?), 
or who might be guaranteed anything (chimps?).

(3) p 3, sec 2. The alt Namespace
Currently deployed projects and protocols that are using pseudo-TLDs may choose 
to move under the .alt pseudo-TLD, but this is not a requirement.
I was wondering whether we could we be slightly stronger here and use 
"recommended to move" rather than "may choose to move"? I.e., I think that the 
IETF position could reasonably be that we would like these to all turn up under 
alt and not squat in the root namespace.

This works for me - it's not a requirement, and so people can happily ignore 
it. Of course, even if it were a requirement, people can still happily ignore 
it… 
(https://i.cbc.ca/1.3173445.1438223040!/fileImage/httpImage/image.jpg_gen/derivatives/16x9_780/winnipeg-blue-bombers.jpg)


Nit level comments:
(4) p 6, sec Appendix A. Changes / Author Notes.
* During AD review, made a few more requested changes
As a minor nit, I think that these comments were during the WGLC, rather than 
AD review.


Fair 'nuff, fixed.

I also added some additional names to the acknowledgement section - *huge* 
apologies to anyone we may have missed…

Warren.

[0]: I know this for a fact, as she doesn't actually exist :-P



On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton 
mailto:rwil...@cisco.com>> wrote:

Hi authors, WG,

Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They are all 
minor/nit comments, meaning that I'll leave it to the authors discretion as to 
how they want to handle these comments.

Minor level comments:

(1) p 3, sec 2. The alt Namespace

Groups wishing to create new alternative namespaces may create their 
alternative namespace under a label that names their namespace under the .alt 
pseudo-TLD. The .alt namespace is unmanaged.

This seems slightly strong given that the ISE draft is planning on setting up a 
registry somewhere. So, perhaps "The .alt namespace is not managed by the IETF 
or IANA"?

(2) p 3, sec 2. The alt Namespace

This document
does not define a registry or governance model for the .alt namespace. 
Developers, applications and users should not expect unambiguous mappings from 
names to name resolution mechanisms.

Is "Developers, applications, users should not expect unambiguous mappings" a 
bit strong? A possible alternative could be: "Developers, applications and 
users are not guaranteed to have unambiguous mappings from names to name