[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bcp-05: (with DISCUSS and COMMENT)

[Paul Wouters via Datatracker]

Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dnssec-bcp-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/



--
DISCUSS:
--


Since draft-ietf-dnsop-rfc5933-bis is in IETF Last Call now, I think it is
worth waiting on and updating this text:

   The GOST signing algorithm [RFC5933] was also adopted, but
   has seen very limited use, likely because it is a national algorithm
   specific to a very small number of countries.

To add a reference that RFCXXX updates the GOST algorithms for DNSSEC (but that
it is uncertain at this point whether it will be widely adopted)

I could be convinced for this document to not wait, but then I do think this
paragraph should state that it is NOT RECOMMENDED to implement RFC5933 since
the underlying GOST algorithms have been deprecated by its issuer.


--
COMMENT:
--


   One purpose is to introduce all of the RFCs in one place so
   that the reader can understand the many aspects of DNSSEC.  This
   document does not update any of those RFCs.  Another purpose is to
   move DNSSEC to Best Current Practice status.

I think another purpose not mentioned, which for me was a main motivator for
this document, is to provide a single RFC reference for other documents that
want to point to "DNSSEC" using a single reference instead of referring to the
3 core components (in an incomplete way)

   More than 15 years after the DNSSEC specification was published, it
   is still not widely deployed.  Recent estimates are that fewer than
   10% of the domain names used for web sites are signed, and only
   around a third of queries to recursive resolvers are validated.

What is the value of this paragraph? You wouldn't want to have a single IPv6
reference RFC say this either :)

This document will be "the reference RFC" for a long time. It should not have
dated/outdated statistics in it.

   However, this low level of implementation does not affect whether
   DNSSEC is a best current practice

I don't think the level of implementation is low. It is actually quite high.
Practically all DNS software implements it. I think you meant deployment ?

NITS:

   which algorithms recursive resolver operators should or should not
   validate.

change to:

   which algorithms recursive resolver operations should or should not
   use for validation

(the algorithms themselves are not validated)



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

[DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-dnssec-bcp-05: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-dnssec-bcp-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/



--
COMMENT:
--

Thank you to Catherine Meadows for the SECDIR review.

** Section 1.1
   Recent estimates are that fewer than
   10% of the domain names used for web sites are signed, and only
   around a third of queries to recursive resolvers are validated.

Since this is a point-in-time measurement, this document would age better with
a reference to these figures.

** Section 1.1
   However, this low level of implementation does not affect whether
   DNSSEC is a best current practice; it just indicates that the value
   of deploying DNSSEC is often considered lower than the cost.
   Nonetheless, the significant deployment of DNSSEC beneath some top-
   level domains (TLDs), and the near-universal deployment of DNSSEC for
   the TLDs in the DNS root zone, demonstrate that DNSSEC is suitable
   for implementation by both ordinary and highly sophisticated domain
   owners.

Editorial style.  The first sentence states that most of the Internet doesn’t
see the value of DNSSEC relative to the cost.  The second sentence suggests
that it is “suitable for … ordinary domain owners.”  I might have used the word
“applicable for …” because for me, part of suitability is that it is that the
cost is acceptable for many in the target population (which the first sentence
suggests it is not)

** Section 2.
   Earlier iterations have not been deployed on a significant scale.

Consider if the text can qualify the differences in scale from the one posed on
Section 1.1 (i.e., <10% of the domain).

** Section 3.
   Cryptography improves over time, and new algorithms get adopted by
   various Internet protocols.

Consider rephrasing this statement.  Overtime, existing cryptographic
algorithms typically weaken as computing power and new cryptoanalysis emerges.



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

Re: [DNSOP] Possible alt-tld last call?

[Martin Schanzenbach]

On OCT17@11:53, Paul Wouters wrote:
> On Mon, 17 Oct 2022, Eliot Lear wrote:
> 
> > Let's please leave Internet lawyering to lawyers.  If people want a
> > legal opinion on this draft, the IETF does have resources for that.
> 
> But it is to the core of the ICANN / IETF divide, so IETF shouldn't wade
> into ICANN territory.
> 
> > We cannot assume that DNS will forever be the only Good approach and
> > that all others will forever be Bad. Given that, we as a community are
> > obligated to search for better, and to try new things.
> 
> Sure. The IETF method is to start a BoF, form a WG, do your thing. See
> Speedy/QUIC. See SSL/TLS, See PGP/OpenPGP.
> 

I am a bit confused now. Let's say there is BoF and, eventually, a WG.
How is that WG supposed to "do it's thing" with respect to alternative
name spaces if there is literally no way to safely use and test it's
results alongside DNS?
Wouldn't such a WG need the .alt as a prerequisite to any actual work or
at least have .alt as its first work item?
Would especially dnsop not care if another WG starts defining a protocol
that is able to resolve names that look like/are DNS names because it is
designed to possibly replace it in the future?

BR

> > There exist many registries for things the IETF doesn't recommend.  One
> > need look no further than TLS 1.3 crypto-suites as an example.
> 
> These are not equivalent. For TLS to interop with non-IETF stuff, they
> need codepoints for within the IETF defined TLS protocol. They are not
> replacing TLS with something else on port 443. (and on top, non-TLS WG
> entries are marked as NOT RECOMMENDED)
> 
> > No matter what we say in the ALT draft, someone could burden the IETF
> > with a new draft.  People do so every day.  If it gains sufficient
> > support, it would have to be at least considered, no matter the topic.
> 
> Sure, but "replacing DNS with something else", would definitely not be
> in dnsop, or the ISE, but via BoF and a new WG. I dout any of the
> alternatives would follow that approach, especially as I cannot see us
> starting a new (replacement or not) naming scheme where there is a new
> landrush for domain names with all of its ICANNlike associated problems.
> 
> I can see DNS 2.0 that replaces all of DNS, but would still hook into
> the existing EPP and RRR ICANN model though. Again, that would not go
> via the ISE path.
> 
> Paul
> 
> ___
> 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

[DNSOP] draft-homburg-add-codcp potential new work for WG?

[Benno Overeinder]

Dear WG,

The DNSOP WG chairs welcome feedback on the draft 
draft-homburg-add-codcp, Control Options For DNS Client Proxies 
(https://datatracker.ietf.org/doc/draft-homburg-add-codcp/).


The draft was submitted to the ADD WG for discussion and review, but the 
WG chairs and the int area AD considered it work outside the ADD WG 
charter.  However, the WG chairs of ADD and DNSOP and the ADs of both 
WGs regard this draft as relevant work.  Individuals in the IETF also 
showed interest and saw the value of the draft.


The chairs are seeking feedback from the DNSOP WG whether this work can 
be discussed in the WG.  The chairs of the DNS-related WGs see no other 
working group where the draft can be presented, while we prefer to let 
the work go through the IETF process via a WG.



Best regards,

-- Benno




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

Re: [DNSOP] Possible alt-tld last call?

[Brian Dickson]

On Sun, Oct 16, 2022 at 8:03 AM Suzanne Woolf  wrote:

> Dear Colleagues,
>
>
> The chairs have gotten a couple of requests, off-list and on, for a WGLC
> on draft-ietf-dnsop-alt-tld.
>
> We’ve reviewed the current draft closely and have some concerns that we
> feel need to be resolved before any effort to move the draft forward.
> (Suzanne wrote this but it’s been discussed among all of the co-chairs.)
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>

Having re-read this draft, and having re-read 6761, I think that "alt"
should NOT be added to the SUDN.
The logic is that the SUDN is for DNS domain names only, and "alt" is
explicitly for non-DNS names.
(Even though it is tempting to include "alt" to give information to those
wanting to do non-DNS names, it's still probably best to not do that, IMHO.)


>
> First, this creates a process problem in that RFC 6761 is the
> standards-track document that specifies how the SUDN registry is to be
> administered, so a request that doesn’t meet the requirements in 6761 can’t
> (or at least shouldn’t) go into the registry.
>
> RFC 6761 section 4 asserts:
>
> The specification also MUST state, in each of the seven "Domain Name
> Reservation Considerations" categories
> below, what special treatment, if any, is to be applied.
>
>
> The alt-tld draft ignores this MUST, without explanation (unless I missed
> it).
>
> The substantive issue is that the questions in Section 5 are there to make
> sure there’s a full description of the expected handling of a proposed name
> by the assorted components that take part in DNS operations and protocol.
> The draft answers at least some of the Section 5 questions, but the answers
> are largely implied.
>
> For example, the draft says that DNS resolvers seeing .alt names "do not
> need to look them up in the DNS context”, but a big part of the point of
> codifying these names is the assumption that queries will leak and DNS
> servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s
> implied that .alt is simply not in the public DNS root zone and the root
> servers (or better yet, any intermediate resolver) should answer “name
> error”/NXDOMAIN for such queries. But this should probably be said
> explicitly, because people who configure DNS servers and services shouldn’t
> have to guess what’s being implied here. (The WG discussed the possibility
> that such queries should be blackholed and not answered at all, which is in
> some ways an obvious answer. Clarification of why this was discarded might
> also be helpful.)
>

I think there should be some instructions to parties wanting to implement
non-DNS name systems on additional requirements or anti-requirements, to
further reduce the likelihood of queries reaching DNS servers.
Specifically, I think having words to the effect of, "Alternative
namespaces SHOULD NOT (or MUST NOT) use the port numbers reserved for DNS
(including but not limited to 53 and 853)."

If they are not DNS they need to not be DNS. Private DNS is still DNS,
which is semantically different from alternative namespaces.
DNS resolvers are expected to be able to handle public and private DNS
names. Alternative namespaces have the potential to collide with DNS names.
As such, resolvers should be DNS or not-DNS, but never both.


>
> So, the current draft isn’t meeting the requirements for the registry, and
> also doesn’t clearly answer substantive questions about what DNS operators
> are expected to do. This makes me uncomfortable doing a WGLC without a new
> rev. It would be Rob Wilton’s call of course (as AD for this draft,
> substituting for Warren) but I’m really uneasy with a WGLC without those
> changes— they seem rather too large to punt for a post-WGLC version.
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
> basis that having the IETF “recognize” (if only by recording) such
> pseudo-delegations may serve to attract unwanted attention to the IETF’s
> supposed recognition of alternate (non-DNS) namespaces as reservations of
> the namespace from the shared, common DNS root. We’re still being denounced
> in certain corners for .onion. It might be good to have a paragraph calling
> out specifically why .alt is not a delegation of a TLD from the DNS root by
> the IETF, even though it looks like one. (We didn’t invent this problem,
> because we didn’t make the decision that top-level domain labels should be
> used by other protocols in a way that led to confusion. But let’s not
> propagate it.)
>

If each alternate namespace uses its own port numbers, there would not even
be a need for any SLD for any such namespace.
Using the "alt" RML (rightmost label) would still be a good thing to
recommend so DNS has some ability to recognize and reject lookups for other
namespaces.
(I.e. use a belt and suspenders philosophy)


>
> 3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term
> “registered” 

[DNSOP] IETF 115 Call for Agenda Items DNSOP WG

[Benno Overeinder]

Dear WG,

This is a Call for Agenda Items for the IETF 115 in London, UK.

DNSOP WG is scheduled on Tuesday, 8 November at 09:30-11:30 (GMT/UTC).

(See for IETF 115 agenda https://datatracker.ietf.org/meeting/115/agenda)


Please email the chairs  with your requests. *Or* 
drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf115 
look for dnsop-ietf115-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 24 October 2022.

See https://datatracker.ietf.org/meeting/important-dates/:
2022-10-24	Monday	Internet Draft submission cut-off (for all drafts, 
including -00) by UTC 23:59 Upload using the ID Submission Tool 
https://datatracker.ietf.org/submit/.



Thanks,

Suzanne
Tim
Benno

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

Re: [DNSOP] Possible alt-tld last call?

[Ben Schwartz]

While we're talking about this draft, I would like to suggest that the
draft discuss the interpretation of URIs containing ".alt" hostnames.  I
have great difficulty understanding what "https://example.foo.alt/; means
... but most of the interest in alternative naming systems seems to be
based on the idea that this sort of URI is meaningful.

Personally, my intuition is that there is a big difference between naming
systems that essentially reuse the DNS RR types, and perhaps can thereby
reuse DNS-bound URI schemes (via a new "virtual DNS interface"), and those
that do not and cannot.  For the latter, new URI schemes would be needed.
This seems to be the essential logic behind the W3C DID effort, which
starts from a new URI scheme.


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Possible alt-tld last call?

[Brian Dickson]

Speaking only for myself (and definitely not for my employer, GoDaddy)...

On Sun, Oct 16, 2022 at 11:45 PM Eliot Lear  wrote:

>
> On 17.10.22 04:20, Paul Wouters wrote:
>
> > Basically, .alt is what IETF recommends you should not do, and we
> > should not keep
> > a registry of entries within it.
>
> We cannot assume that DNS will forever be the only Good approach and
> that all others will forever be Bad. Given that, we as a community are
> obligated to search for better, and to try new things.  As I wrote
> earlier, I do not know that GNS will succeed. I do hope and expect that
> the community will learn something from some deployment experience of
> that protocol so that the next one can be better.
>
>
I think that the concerns of namespace and root(s) is essentially this:

   - The Domain Name System has the ICANN Root as its source of legitimacy,
   and the IETF as its standards body.
   - Other namespaces need to be effectively "ships in the night" with
   respect to The Domain Name System
  - This means no interoperation between "not-DNS" and "DNS" at a name
  space layer.
  - Specifically, as long as any other name resolution scheme has no
  overlap with any portion of the DNS tree, what names that other system
  contains is a moot point (even if they superficially appear to collide)
   - The alternative (allowing non-DNS services to also directly
   incorporate the DNS tree) has a high likelihood of causing user confusion
   or worse.
  - Any alternative systems should stand entirely on their own, and
  their success or failure would be possible to objectively assess.
  - The only place where multiple systems (DNS and any non-DNS) should
  be combined is the same place they have always been,
/etc/nsswitch.conf (or
  equivalent)
   - Experimentation and development of standards can only happen safely
   when unrelated systems don't overlap or conflict.
   - This suggestion would be the antithesis of the "Good vs Bad"
   viewpoint, and IMNSHO consistent with what DNSOP does already.

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

Re: [DNSOP] [EXTERNAL] Possible alt-tld last call?

[Paul Wouters]

On Mon, 17 Oct 2022, Suzanne Woolf wrote:


One could advance the 6761bis proposal document first, which would
remove these non-compliance items as those would be no longer needed
(as the bis document proposal removes it as these were not consistently
required in the past). Alternatively, ignoring it wouldn't be the first
time these are ignored, so I guess there is a precedence of ignoring it.


I've read the 6761bis draft (draft-hoffman-rfc6761bis), and it struck me as a 
bit baffling that the proposed answer to a couple of cases of non-compliance 
with a MUST in a standards-track registry policy document is to throw out the 
MUST, rather than address a possible problem with approving or processing 
requests.


I believe it is more than "a couple". I think Paul Hoffman has the
numbers.


More to the point, the questions are there to make sure that DNS operators (and others) 
know what is required of their configurations and protocols in order to interoperate 
between DNS and non-DNS operations and protocols that are using domain name conventions 
for their names. The draft appears to propose keeping the original registry policy 
("Standards Action or IESG Approval") while reducing the amount of information 
required as a basis for a decision, which seems unlikely to make things any easier or 
more effective for the IESG, DNS operators and implementers, or anyone else.


Seeing as we are in a 5+ year stalemate, I am not sure how it could not
be "more effective".

But I think you are mixing up two things. Entries under .arpa and new
"TLD like" entries. The latter has seen lots of pushback, including from
dnsops (eg the .home proposal getting pushed into home.arpa).

The entries for .arpa are well discussed, well formed drafts, and while
they might require special handling, most do not. Those who do are well
specified (eg resolver.arpa) and see full work done within their
respective WGs to reach RFC status in the proper way. And on top of
that, from now on will see review from the DNS Directorate as well.

TLD requests however, have always been a minefield and dnsop is not
the right place for discussing these. It often has fairly little to
do with the actual DNS protocol or operations.


Recall that the request for .onion (RFC 7686) was initiated under the same 
registry policy we have today, and the IESG could have offered its approval 
without DNSOP (or anyone else) providing a standards-track document taken 
through normal WG process. They preferred giving it to the IETF WG whose 
constituency is DNS operators and implementers.


The IESG handed DNSOP a problem to solve via https://www.ietf.org/blog/onion/

However, subsequent to this action, the IESG believes RFC 6761 needs
action, and substantial community input. It needs to be open for review
and modification because the current process is unscalable. Several
other names had also been submitted for consideration as special names,
and the RFC may not give adequate guidance about how when names should
be identified as special names. Special names should also be, as the
name implies – special and rare. The DNSOP working group is chartered
to address this RFC 6761 review.

But 7 years later, there is still no published 6761bis. I would therefor
argue that DNSOP has proven to not be the right place to do this. I do
not see how you can turn that into a "[the IESG] preferred giving it to
the IETF WG whose constituency is DNS operators and implementers.". I
mean the "preferred" in the past tense is correct. I am not sure the
current IESG still agrees after 7 years.


In other words, I've always thought that all of Section 5, including the MUST, 
is there to support interoperability, and removing the requirement to provide 
relevant information seems like a step backwards for that goal.


While that makes sense for entries in .arpa, it hardly makes sense for
new TLD-like domains that are per definition non-DNS (if they were DNS,
then ICANN should be dealing with those TLD names).


I think it draft would be better if it said something along the lines
of:

No code changes are required to properly handle leaked queries for .alt
into the DNS, but:

1) Implementations MAY handle .alt specially by (pre)fetching the proofs
of non-existence of .alt and serve these for all .alt queries.
2) implementations MAY rely on their query minimalization to accomplish 1)
3) or MAY do nothing special, which should work fine but might leak SLD
queries to the root if the implementation and its querier didn't do query
minimalization)
4) MAY return FORMERR on .alt queries that in some ways violate the DNS
specification (so that no code changes are mandatory to support the
madness .alt queries could bring in, eg >63 SLD names)


This is the kind of detail I think is important to provide in a document that's 
essentially about interoperability, whether it's explicitly required or not. 
Thank you.


Sure, it would be nice 

[DNSOP] John Scudder's Yes on draft-ietf-dnsop-dnssec-bcp-05: (with COMMENT)

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-dnsop-dnssec-bcp-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/



--
COMMENT:
--

Thanks, Paul, for this useful and easy-to-read document. Thanks also to Tim
Wicinski for putting in the work to build the excellent evaluation table.

## COMMENT

### Section 1

~~~
   This document lists many (but not all) of the RFCs that should be
   considered by someone creating an implementation of, or someone
   deploying, modern DNSSEC.
~~~

Why not list all the ones that should be considered? That seems like a bit of a
tease! But maybe (probably?) you meant that the list is not guaranteed
comprehensive, in which case perhaps something like this

~~~
   This document lists RFCs that should be
   considered by someone creating an implementation of, or someone
   deploying, modern DNSSEC. Although an effort was made to be
   thorough, it would be unwise for the reader to assume this list
   is comprehensive.
~~~

could be used.

But maybe you meant exactly what you wrote, in which case, OK.



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

Re: [DNSOP] Possible alt-tld last call?

[Brian Dickson]

On Mon, Oct 17, 2022 at 7:12 AM Joe Abley  wrote:

>
> My goal is certainly not to put any brakes on if the effect of that is to
> make things move more slowly. I apologise if that's what I have done in
> suggesting to Brian that semantic-free labels do not fit the problem space.
>
>
And I, in return, apologise for my idea. Clearly, not a good idea, although
maybe useful for discussing concepts, and reaching conclusions about such a
registry.

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

Re: [DNSOP] Possible alt-tld last call?

[Warren Kumari]

On Sun, Oct 16, 2022 at 7:20 PM, Paul Wouters  wrote:

> On Sun, 16 Oct 2022, Suzanne Woolf wrote:
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>
> One could advance the 6761bis proposal document first, which would remove
> these non-compliance items as those would be no longer needed
> (as the bis document proposal removes it as these were not consistently
> required in the past). Alternatively, ignoring it wouldn't be the first
> time these are ignored, so I guess there is a precedence of ignoring it.
>
> For example, the draft says that DNS resolvers seeing .alt names "do not
> need to look them up in the DNS context”, but a big part of the point of
> codifying these names is the assumption that queries will leak and DNS
> servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s
> implied that .alt is simply not in the public DNS root zone and the root
> servers (or better yet, any intermediate resolver) should answer “name
> error”/NXDOMAIN for such queries. But this should probably be said
> explicitly, because people who configure DNS servers and services shouldn’t
> have to guess what’s being implied here. (The WG discussed the possibility
> that such queries should be blackholed and not answered at all, which is in
> some ways an obvious answer. Clarification of why this was discarded might
> also be helpful.)
>
> I think it draft would be better if it said something along the lines of:
>
> No code changes are required to properly handle leaked queries for .alt
> into the DNS, but:
>
> 1) Implementations MAY handle .alt specially by (pre)fetching the proofs
> of non-existence of .alt and serve these for all .alt queries.
> 2) implementations MAY rely on their query minimalization to accomplish 1)
> 3) or MAY do nothing special, which should work fine but might leak SLD
> queries to the root if the implementation and its querier didn't do query
> minimalization)
> 4) MAY return FORMERR on .alt queries that in some ways violate the DNS
> specification (so that no code changes are mandatory to support the madness
> .alt queries could bring in, eg >63 SLD names)
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me
>
> Me too, I really do believe that the IETF should not do this. It is an
> anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
> Some alternative sysytems might even use .alt without SLD. Basically,
> .alt is what IETF recommends you should not do, and we should not keep a
> registry of entries within it.
>
> But also, IETF maintaining a list might open it up for legal liabilities
> with alternative naming systems. The whole idea of the ICANN/IETF split is
> that ICANN does money and legal stuff, and IETF does codepoints and running
> code (with no money) :P
>
> So I disagree with Eliot who prefered some kind of FCFS registry that
> requires RFCs to get an entry. We do not want alternative naming systems to
> require (and burden) the IETF with RFCs.
>



#include 

I'll note that I was one of the people initially pushing for a registry - I
wanted to be able to lookup 'foo.alt' and see that I should read the
specifications "The foo naming system", available on GitHub at  (and
possibly also "foo-names - the protocol" available at ).

But:
1: as we've already seen, nothing stops people from just using whatever
names they want[0], and so there is no guarantee that registry would be
complete and correct.
2: if this happens to be widely used, we might end up with lots and lots of
names using this, and having e.g the IANA maintain this has costs - even if
they just note "FooNet says that they use foo.alt and their specification
is at https://www.the-foo-project.example/foo-names.html;, this has costs.
I really don't want us to end up with a "success failure".

Having something like a list of what to read to understand how to resolve
bar.foo.alt still seems useful, but it could (IMO) just be a list on GitHub
that someone is willing to manage (similar to the PSL (
https://github.com/publicsuffix/list), but purely informational, and with
no real validation/work. And, no, I'm not volunteering to run this).

W
[0]: I just changed the hostname on my laptop bar.foozle.wobble.alt, and
there is nothing you can do to stop me… (actually I didn't, but I could
have)




> 3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term
> “registered” differently than common usage. Judging from searches on RFC
> 6761 and RFC 8499, it’s ambiguous for DNS naming and resolution, and
> “registered” can definitely mean something different to a registry or
> registrar than it does to a DNS operator. To people who operate TLD
> registries, a name can be “registered” and still may or may not be
> delegated. (“Label” is defined in 8499,
> “register” and “delegate” are not.) And, in the reference to “TLD,” it
> feels strange to expand the acronym to
> “Top-level label” even if “label” is the 

Re: [DNSOP] Possible alt-tld last call?

[Warren Kumari]

On Sun, Oct 16, 2022 at 11:44 PM, Eliot Lear  wrote:

> Hi Paul!
>
> Good conversation!  I hope we can discuss some of this "in person"
> (whatever that means these days) at IETF 115.
>
> On 17.10.22 04:20, Paul Wouters wrote:
>
> On Sun, 16 Oct 2022, Suzanne Woolf wrote:
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>
> One could advance the 6761bis proposal document first, which would remove
> these non-compliance items as those would be no longer needed
> (as the bis document proposal removes it as these were not consistently
> required in the past). Alternatively, ignoring it wouldn't be the first
> time these are ignored, so I guess there is a precedence of ignoring it.
>
> If what you are saying is that we shouldn't get hung up on 6761, then I
> agree.  There are, I think, many ways to deal with the issue that Suzanne
> raised.  One possibility not mentioned was to simply slap an
> "Updates" header on this draft if we think it's necessary, but that
> wouldn't be my first choice.
>

Note: I'm at NANOG this week (and also dealing with dayjob and some other
issues), and so I'm likely to be distracted and not able to focus on this
discussion as much as I'd like. Apologies in advance if I'm replying to
threads midway though / am terser than usual...



I really really don't think that "slap an "Updates" header on this draft"
is a good idea — the WG put a large amount of work into RFC 8244
("Special-Use Domain Names Problem Statement"). RFC 8244 lists 21 top level
issues and includes:
"This document has two goals: enumerate all of the problems that have been
identified to which Special-Use Domain Names are a solution and enumerate
all of the problems that have been raised in the process of trying to use
RFC 6761 as it was intended."

The document also notes that there have been cases where we've messed up
the process:
" 11.  In some cases where the IETF has made assignments through the
process defined in RFC 6761, technical mistakes have been made
due to misunderstandings as to the actual process that RFC 6761
specifies (e.g., treating the list of suggested considerations
for assigning a name as a set of requirements, all of which must
be met).  In other cases, the IETF has made de facto assignments
of Special-Use Domain Names without following the process in RFC
6761 (see [RFC7050] and [RFC7788])."
Some of these process issue have included places where the IETF/IESG/IANA
missed that the fact that documents which added to the registry didn't
include the RFC6761 required bits ("The specification also MUST state, in
each of the seven "Domain Name Reservation Considerations" categories
below, what special treatment, if any, is to be applied.")

However, just because we screwed up in the past and added things to the
registry without following the process (and just because we think that some
of the questions are sub-optimal / inconvenient) doesn't mean that the
right thing to do is to just rip-em-out with an Updates tag. This is
especially true because of how much work the WG put into the "Problem
Statement" document - if there had been clear consensus that that was a
good idea we could have done it then.

I'll also note that while I personally think that some of the questions
could be worded better, the very act of filling them out focuses the
discussions and helps frame the answers in a manner which is useful.

Yes, my life as an author would have been easier not having to try and
figure out the answers to things like:
"  4: Are developers of caching domain name servers expected to make
   their implementations recognize these names as special and treat
   them differently?"
(See earlier discussion - differently to what? If the names are in the
Locally Served Zones registry does that count? Is it specifically
"developers" or "operators" (is this a "code vs configuration" question?)

But, the fact that I had to think about and answer them was really useful,
even if the questions themselves could have been better worded.

W

> The bigger issue is below.  IMHO if we can kink that out, we have
> ourselves a ballgame.
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me
>
> Me too, I really do believe that the IETF should not do this. It is an
> anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
> Some alternative sysytems might even use .alt without SLD.
> [...]
> But also, IETF maintaining a list might open it up for legal liabilities
> with alternative naming systems.
>
> Let's please leave Internet lawyering to lawyers.  If people want a legal
> opinion on this draft, the IETF does have resources for that.
>
> So I disagree with Eliot who prefered some kind of FCFS registry that
> requires RFCs to get an entry. We do not want alternative naming systems to
> require (and burden) the IETF with RFCs.
>
> I am struggling to parse that sentence, but 

Re: [DNSOP] Possible alt-tld last call?

[Rob Wilton (rwilton)]

Hi Joe,

> -Original Message-
> From: Joe Abley 
> Sent: 16 October 2022 20:30
> To: Brian Dickson 
> Cc: Eliot Lear ; Rob Wilton (rwilton) ;
> Suzanne Woolf ; dnsop@ietf.org; DNSOP-Chairs Chairs
> 
> Subject: Re: [DNSOP] Possible alt-tld last call?
> 
> Op 16 okt. 2022 om 15:03 heeft Brian Dickson
>  het volgende geschreven:
> 
> > For example, using a hash function, such as sha2-256, with output encoded
> as base32hex.
> > (This is just an example; any suitable function that takes URI as input and
> produces an ASCII DNS-compatible label as output would suffice.)
> 
> If we start from the position that names in this shared namespace don't need
> to be semantically meaningful to humans then this whole problem space
> becomes a whole lot easier, or perhaps doesn't even rise to the level of
> "problem". See also 98% of the work done by the ICANN community and
> arguably the entire business models of registries and registrars.
> 
> However, I don't think we are starting from that position. For example we
> hear there is demand for .giraffe for the giraffe naming system described at
> https://giraffe.org/ because using giraffe.org as an anchor for that naming
> system in the namespace is not acceptable to anybody who cares about GNS.
> 
> If giraffe.org doesn't cut the mustard then I have my doubts that
> jduxbenebrnjxudnxznbrnr.alt will satisfy anybody either.
> 
> (If giraffe.org can't be tolerated then I also don't see why giraffe.alt is an
> obvious solution, but I sense people are tired of hearing me say that so I'll
> leave it this parenthetical cloak of invisibility and continue whistling
> innocently.)

You may be right, but I don't think that we can really know this unless we try. 
 And at least if we did standardize .alt then we are offering a sanctioned 
mechanism for supporting alternative domain resolution systems.

I think that we know that gns is willing to use .alt, so we have at least one 
taker.

Rob
// No hats.

> 
> 
> Joe

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

Re: [DNSOP] Possible alt-tld last call?

[Andrew Sullivan]

Dear colleagues,

I work for the Internet Society but this is emphatically not the position of 
the Internet Society.

On Sun, Oct 16, 2022 at 03:03:10PM +, Suzanne Woolf wrote:


2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the basis 
that having the IETF “recognize” (if only by recording) such pseudo-delegations 
may serve to attract unwanted attention to the IETF’s supposed recognition of 
alternate (non-DNS) namespaces as reservations of the namespace from the 
shared, common DNS root. We’re still being denounced in certain corners for 
.onion. It might be good to have a paragraph calling out specifically why .alt 
is not a delegation of a TLD from the DNS root by the IETF, even though it 
looks like one. (We didn’t invent this problem, because we didn’t make the 
decision that top-level domain labels should be used by other protocols in a 
way that led to confusion. But let’s not propagate it.)



I think I might not entirely agree with the reasoning above, but I very 
strongly agree that it would be a bad idea to create a registry for this 
innovation with any change control either held or delegated by the IETF.

The point of the alt namespace, if it has any point at all, is to create a protocol-switch in the 
DNS using in-band signalling via a label.  That protocol switch is there to say, "You are now 
outside the DNS."  It is a mechanism by which someone could in principle put these alternative 
identifiers into what may be thought of as "domain name slots" and hope that somehow 
there is the appropriate handler for such identifiers to work.

Attempting to police or advise about such a chaotic namespace is a doomed venture.  There 
is little reason to suppose it won't be polluted with entries that do not work or that 
cease to work over time.  There is little reason to suppose that any exclusivity rule 
could be enforced, so any protocol wishing to use one of these identifiers needs to be 
prepared to deal with another, conflicting use of the same name anyway.  (To show why 
this is true, consider the use of labels like .home and .lan that were not registered in 
the DNS but that were in wide use by various independent operators in not-very-consistent 
ways.  At least in that case, they all used the DNS wire format.)  And, since alt is 
explicitly saying, "You're not in the DNS," there's not even a single protocol 
that will want these kinds of identifiers.

Anyone who has been through a corporate renumbering that resulted from 
corporate merger and the discovery of awkward RFC 1918 number collisions knows 
that there are basically two kinds of registries for identifiers on the 
Internet: globally-unique registries, and everything else.  There is no way to 
make this a globally unique registry, and yet someone will surely think that by 
getting their label in it they have some claim on that label.  This puts 
whoever is maintaining the registry squarely in the crosshairs of litigious 
people for whom technical reality is no barrier to argument.

Finally, it seems to me that the creation of such a registry presents a serious 
problem for IANA.  IANA, recall, is in part subject to a Customer Standing 
Committee with representation from three operational communities.  If I came 
from the names operational community and saw IANA setting up a registry for 
something that at first glance will look like an end run around names community 
processes (however justified such processes might be), I would ask some pretty 
pointed questions about what IANA is doing.

So, to my mind, creating a registry that won't have any real effect, that won't 
scale, that will almost certainly hold useless registrations, and that presents 
both political and legal risks for the Internet, is something a document 
shouldn't do.

Best regards,

A

--
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Possible alt-tld last call?

[Paul Wouters]

On Mon, 17 Oct 2022, Eliot Lear wrote:

Let's please leave Internet lawyering to lawyers.  If people want a legal 
opinion on this draft, the IETF does have resources for that.


But it is to the core of the ICANN / IETF divide, so IETF shouldn't wade
into ICANN territory.

We cannot assume that DNS will forever be the only Good approach and that all 
others will forever be Bad. Given that, we as a community are obligated to 
search for better, and to try new things.


Sure. The IETF method is to start a BoF, form a WG, do your thing. See
Speedy/QUIC. See SSL/TLS, See PGP/OpenPGP.

There exist many registries for things the IETF doesn't recommend.  One need 
look no further than TLS 1.3 crypto-suites as an example.


These are not equivalent. For TLS to interop with non-IETF stuff, they
need codepoints for within the IETF defined TLS protocol. They are not
replacing TLS with something else on port 443. (and on top, non-TLS WG
entries are marked as NOT RECOMMENDED)

No matter what we say in the ALT draft, someone could burden the IETF with a 
new draft.  People do so every day.  If it gains sufficient support, it would 
have to be at least considered, no matter the topic.


Sure, but "replacing DNS with something else", would definitely not be
in dnsop, or the ISE, but via BoF and a new WG. I dout any of the
alternatives would follow that approach, especially as I cannot see us
starting a new (replacement or not) naming scheme where there is a new
landrush for domain names with all of its ICANNlike associated problems.

I can see DNS 2.0 that replaces all of DNS, but would still hook into
the existing EPP and RRR ICANN model though. Again, that would not go
via the ISE path.

Paul

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

Re: [DNSOP] [EXTERNAL] Possible alt-tld last call?

[Suzanne Woolf]

Hi,


> On Oct 16, 2022, at 10:20 PM, Paul Wouters  wrote:
> 
> On Sun, 16 Oct 2022, Suzanne Woolf wrote:
> 
> > 1. As far as I can tell, this draft does not comply with RFC 6761. This is 
> > a problem for two reasons.
> 
> One could advance the 6761bis proposal document first, which would
> remove these non-compliance items as those would be no longer needed
> (as the bis document proposal removes it as these were not consistently
> required in the past). Alternatively, ignoring it wouldn't be the first
> time these are ignored, so I guess there is a precedence of ignoring it.

I've read the 6761bis draft (draft-hoffman-rfc6761bis), and it struck me as a 
bit baffling that the proposed answer to a couple of cases of non-compliance 
with a MUST in a standards-track registry policy document is to throw out the 
MUST, rather than address a possible problem with approving or processing 
requests. 

More to the point, the questions are there to make sure that DNS operators (and 
others) know what is required of their configurations and protocols in order to 
interoperate between DNS and non-DNS operations and protocols that are using 
domain name conventions for their names. The draft appears to propose keeping 
the original registry policy ("Standards Action or IESG Approval") while 
reducing the amount of information required as a basis for a decision, which 
seems unlikely to make things any easier or more effective for the IESG, DNS 
operators and implementers, or anyone else.

Recall that the request for .onion (RFC 7686) was initiated under the same 
registry policy we have today, and the IESG could have offered its approval 
without DNSOP (or anyone else) providing a standards-track document taken 
through normal WG process. They preferred giving it to the IETF WG whose 
constituency is DNS operators and implementers.

In other words, I've always thought that all of Section 5, including the MUST, 
is there to support interoperability, and removing the requirement to provide 
relevant information seems like a step backwards for that goal. 

> I think it draft would be better if it said something along the lines
> of:
> 
> No code changes are required to properly handle leaked queries for .alt
> into the DNS, but:
> 
> 1) Implementations MAY handle .alt specially by (pre)fetching the proofs
> of non-existence of .alt and serve these for all .alt queries.
> 2) implementations MAY rely on their query minimalization to accomplish 1)
> 3) or MAY do nothing special, which should work fine but might leak SLD
> queries to the root if the implementation and its querier didn't do query
> minimalization)
> 4) MAY return FORMERR on .alt queries that in some ways violate the DNS
> specification (so that no code changes are mandatory to support the
> madness .alt queries could bring in, eg >63 SLD names)

This is the kind of detail I think is important to provide in a document that's 
essentially about interoperability, whether it's explicitly required or not. 
Thank you.


Suzanne

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

Re: [DNSOP] Possible alt-tld last call?

[Eliot Lear]

On 17.10.22 17:16, Paul Wouters wrote:


But does the IETF, when running a FCFS registry, want to take the legal
liability of your adjudicating? 


Again, Paul, if you want to ask counsel for advice and have them provide 
it here, great.  Otherwise we end up Internet-lawyering, which is also 
when we end up making bad decisions.  Also, my preferred policy would be 
"RFC Required".


Eliot

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

Re: [DNSOP] Possible alt-tld last call?

[Paul Wouters]

On Mon, 17 Oct 2022, Independent Submissions Editor (Eliot Lear) wrote:


On 17.10.22 12:37, Vittorio Bertola wrote:

 Well, I'm just waiting for the request to register amazon.alt.

 (or xxx.alt, or ru[ssia].alt, or .alt, which some
 people will do just for fun)

 Unless, of course, you mean that the ISE will adjudicate trademarks,
 define which strings are offensive and determine whether an applicant has
 the right to use the name of a country or geographical entity, thus
 deciding whether a proposal is "trivial or bad" or not.


I don't want to adjudicate names, but I have no problem adjudicating naming 
systems, including transparent attempts to get vanity names.  Since none of 
those are naming systems, they would all get the official "bubye".


But does the IETF, when running a FCFS registry, want to take the legal
liability of your adjudicating? As the IETF will be seen as the sponsor
behind it, as it will have created the procedure that you will use to
say yes or no.

Paul

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

Re: [DNSOP] Possible alt-tld last call?

[Jim Reid]

> On 17 Oct 2022, at 15:12, Joe Abley  wrote:
> 
> Since it's not clear, my favoured approach to this entire subject is to do 
> whatever is the quickest way to resolve the conversation so that this working 
> group can get on with work that, in my opinion, no disrespect intended, is 
> less pointless. I do not believe this proposal does any harm, since I think 
> it will have a practical effect that is the same as doing nothing at all.

I agree with Joe. The WG’s spent too much time on this issue. It has been 
unable to make useful progress. The prospects of reaching an approximation of 
rough consensus are no closer than they were when this was first discussed. I 
think it’s time for the WG to declare defeat and give up.

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

Re: [DNSOP] Possible alt-tld last call?

[Joe Abley]

On 17 Oct 2022, at 10:06, Martin Schanzenbach  wrote:

> Technically, GNS celebrated its 10th birthday in 2022 ;)

:-)

> But back to business: You cannot think both that alternative name systems are
> fleeting trends and at the same time are a serious threat to DNS namespace
> consistency.
> That does not make sense.

I don't think they are serious threats to DNS namespace consistency.

Since it's not clear, my favoured approach to this entire subject is to do 
whatever is the quickest way to resolve the conversation so that this working 
group can get on with work that, in my opinion, no disrespect intended, is less 
pointless. I do not believe this proposal does any harm, since I think it will 
have a practical effect that is the same as doing nothing at all.

My goal is certainly not to put any brakes on if the effect of that is to make 
things move more slowly. I apologise if that's what I have done in suggesting 
to Brian that semantic-free labels do not fit the problem space.


Joe

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

Re: [DNSOP] Possible alt-tld last call?

[Martin Schanzenbach]

On OCT17@07:11, Joe Abley wrote:
> On Oct 16, 2022, at 23:03, Christian Huitema  wrote:
> 
> > The main problem with "giraffe.org" and similar is that the subdomains are 
> > leased, not owned. A glitch in the renewal, and they are grabbed by some 
> > domain catcher and redirected to "my sexy giraffe" or some such.
> 
> On the face of it that seems like a compelling endorsement of the idea, that 
> the biggest risk is one that has proven not to be a significant problem in 
> aggregate for other lesser-known and marginal uses of the DNS such as, oh I 
> don't know, the web or e-mail.
> 
> The risks in this case are even lower than in those use-cases, since a 
> one-time payment secures a renewable ten year lease which is enough to exceed 
> the effective lifetime of any alternative naming scheme seen to date by quite 
> some margin,

Technically, GNS celebrated its 10th birthday in 2022 ;)
But back to business: You cannot think both that alternative name systems are
fleeting trends and at the same time are a serious threat to DNS namespace
consistency.
That does not make sense.

> 
> Despite your endorsement, however, I suspect people will continue to ignore 
> this approach in favour of squatting on top-level labels, a fate that seems 
> likely to be replicated faithfully with alt. That was the point I was 
> apparently not able to refrain from repeating, really.
> 

I know that is a valid opinion to hold and is difficult to refute
without epiric evidence. However, such a PoV also requires a lucid conclusion 
as consequence.
For example, if it is consensus that .alt is a pointless endeavour because
all/most/a lot of alternative name systems will squat TLDs, the question
becomes: Why do you they squat a TLD?

I think that most alternative name systems squat a specific TLD as a
unique identification. They do not try to squat and replace DNS on purpose.
At the same time I can think of no alternative name system that
could not technically squat on the whole DNS namespace in theory.
In conclusion (and I am repeating myself): You have the unique chance
here to funnel this phenomenon in safe and manageable bounds using .alt.
For that you need to understand why the squatting is happening.

What would you rather have? A document you can point to where you can
tell sqatting name systems that they are "doing it wrong" or a document
that cannot hope to have any effect whatsoever on alternative name systems
because it simply reserves a TLD and tells DNS implementations to "don't
go there".

BR
Martin


> 
> Joe
> ___
> 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] Possible alt-tld last call?

[Jim Reid]

> On 17 Oct 2022, at 13:00, Independent Submissions Editor (Eliot Lear) 
>  wrote:
> 
> I don't want to adjudicate names, but I have no problem adjudicating naming 
> systems, including transparent attempts to get vanity names.  Since none of 
> those are naming systems, they would all get the official "bubye".

Eliot, I have no doubt you’d always do The Right Thing here. That might not be 
the case for the next ISE. Or the one after. Or... Besides, decisions that 
depend on subjective judgements, no matter how clueful, are likely to cause 
inconsistencies and controversy. That’s best avoided IMO - more so for 
something as icky as ad-hoc TLDs. 

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

Re: [DNSOP] Possible alt-tld last call?

[Independent Submissions Editor (Eliot Lear)]

Hi Vittorio,

On 17.10.22 12:37, Vittorio Bertola wrote:

Well, I'm just waiting for the request to register amazon.alt.

(or xxx.alt, or ru[ssia].alt, or .alt, which some people 
will do just for fun)

Unless, of course, you mean that the ISE will adjudicate trademarks, define which strings 
are offensive and determine whether an applicant has the right to use the name of a 
country or geographical entity, thus deciding whether a proposal is "trivial or 
bad" or not.


I don't want to adjudicate names, but I have no problem adjudicating 
naming systems, including transparent attempts to get vanity names.  
Since none of those are naming systems, they would all get the official 
"bubye".


Eliot

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

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

[Макаренко Борис]

Hello, Roni!

The old algorithms GOST R 34.11-94, GOST R 34.10-2001 and GOST R 
34.11-2001 are considered obsolete. They are now replaced with GOST R 
34.10-2012 (digital signature) and GOST R 34.11-2012 (hash function). 
Basically, the use of GOST algorithms in DNSSEC remains the same as 
described in RFC 5933, but it is necessary to replace them with the new 
ones. Old algorithms should not be used anymore. That's why we need to 
obsolete RFC 5933.


The section "IANA Considerations" proposes to assign numbers for GOST R 
34.10-2012 and GOST R 34.11-2012 in the IANA registries "DNS Security 
Algorithm Numbers" 
(https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml) 
and "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" 
(https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml).


Updates for RFC 8624 are described in the corresponding Section.

--
Boris


13.10.2022 14:41, Roni Even via Datatracker writes:
Reviewer: Roni Even Review result: Almost 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-rfc5933-bis-?? Reviewer: Roni Even Review > 
Date: 2022-10-13 IETF LC End Date: 2022-10-19 IESG Telechat date: Not > 
scheduled for a telechat > > Summary: the document is almost ready for 
publication as some type of > an RFC > > Major issues: The document is 
meant to be an informational RFC > obsoleting RFC5933 a standard track 
RFC. why is this change. > > Minor issues: > > the directive in the IANA 
consideration "The entry for Value 3, > GOST R 34.11-94 should be 
updated to have its Status changed to '-'" > is not clear. there is no 
status field in the table as I see in > RFC8624 section 3.3 > > 
Nits/editorial comments: > > > >___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Possible alt-tld last call?

[Joe Abley]

On Oct 16, 2022, at 23:03, Christian Huitema  wrote:

> The main problem with "giraffe.org" and similar is that the subdomains are 
> leased, not owned. A glitch in the renewal, and they are grabbed by some 
> domain catcher and redirected to "my sexy giraffe" or some such.

On the face of it that seems like a compelling endorsement of the idea, that 
the biggest risk is one that has proven not to be a significant problem in 
aggregate for other lesser-known and marginal uses of the DNS such as, oh I 
don't know, the web or e-mail.

The risks in this case are even lower than in those use-cases, since a one-time 
payment secures a renewable ten year lease which is enough to exceed the 
effective lifetime of any alternative naming scheme seen to date by quite some 
margin, and the effect of not renewing presumably only presents risks to 
queries leaked to the DNS which were those that didn't give the user the result 
they were expecting in the first place, anyway.

Despite your endorsement, however, I suspect people will continue to ignore 
this approach in favour of squatting on top-level labels, a fate that seems 
likely to be replicated faithfully with alt. That was the point I was 
apparently not able to refrain from repeating, really.


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

Re: [DNSOP] Possible alt-tld last call?

[Vittorio Bertola]

> Il 17/10/2022 08:44 CEST Eliot Lear  ha scritto:
> 
> Let's please leave Internet lawyering to lawyers.  If people want a 
> legal opinion on this draft, the IETF does have resources for that.
>
> [...]
> 
> No matter what we say in the ALT draft, someone could burden the IETF 
> with a new draft.  People do so every day.  If it gains sufficient 
> support, it would have to be at least considered, no matter the topic.  
> And again, I suspect most of these sorts of documents are more likely to 
> flow to the ISE or perhaps a future IRTF RG.  As the current ISE, that 
> is a burden I would gladly bear, because there is the opportunity to 
> help the Internet community, including the IETF and ICANN.
> 
> I also have no problem rejecting trivial or bad proposals.

Well, I'm just waiting for the request to register amazon.alt.

(or xxx.alt, or ru[ssia].alt, or .alt, which some people 
will do just for fun)

Unless, of course, you mean that the ISE will adjudicate trademarks, define 
which strings are offensive and determine whether an applicant has the right to 
use the name of a country or geographical entity, thus deciding whether a 
proposal is "trivial or bad" or not.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

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

[DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dnssec-bcp-05: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-dnssec-bcp-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/



--
COMMENT:
--

Thanks for this document, I think that it is helpful, and was easy to read.

More generally, out of scope for this work, it would be nice to an updated
document describing all the core aspects of DNS, that would probably be helpful
to the wider community.  I appreciate that such an undertaking would be a
significant amount of less appealing work though ...

Regards,
Rob



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

Re: [DNSOP] Possible alt-tld last call?

[Eliot Lear]

Hi Paul!

Good conversation!  I hope we can discuss some of this "in person" 
(whatever that means these days) at IETF 115.


On 17.10.22 04:20, Paul Wouters wrote:

On Sun, 16 Oct 2022, Suzanne Woolf wrote:

1. As far as I can tell, this draft does not comply with RFC 6761. 
This is a problem for two reasons.


One could advance the 6761bis proposal document first, which would
remove these non-compliance items as those would be no longer needed
(as the bis document proposal removes it as these were not consistently
required in the past). Alternatively, ignoring it wouldn't be the first
time these are ignored, so I guess there is a precedence of ignoring it.


If what you are saying is that we shouldn't get hung up on 6761, then I 
agree.  There are, I think, many ways to deal with the issue that 
Suzanne raised.  One possibility not mentioned was to simply slap an 
"Updates" header on this draft if we think it's necessary, but that 
wouldn't be my first choice.  The bigger issue is below.  IMHO if we can 
kink that out, we have ourselves a ballgame.



2. Having the IETF maintain a registry of pseudo-SLDs concerns me


Me too, I really do believe that the IETF should not do this. It is an
anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
Some alternative sysytems might even use .alt without SLD.
[...]
But also, IETF maintaining a list might open it up for legal liabilities
with alternative naming systems.


Let's please leave Internet lawyering to lawyers.  If people want a 
legal opinion on this draft, the IETF does have resources for that.



So I disagree with Eliot who prefered some kind of FCFS registry that
requires RFCs to get an entry. We do not want alternative naming systems
to require (and burden) the IETF with RFCs.


I am struggling to parse that sentence, but taken together with this...

Basically, .alt is what IETF recommends you should not do, and we 
should not keep
a registry of entries within it. 


We cannot assume that DNS will forever be the only Good approach and 
that all others will forever be Bad. Given that, we as a community are 
obligated to search for better, and to try new things.  As I wrote 
earlier, I do not know that GNS will succeed. I do hope and expect that 
the community will learn something from some deployment experience of 
that protocol so that the next one can be better.


There exist many registries for things the IETF doesn't recommend.  One 
need look no further than TLS 1.3 crypto-suites as an example.


No matter what we say in the ALT draft, someone could burden the IETF 
with a new draft.  People do so every day.  If it gains sufficient 
support, it would have to be at least considered, no matter the topic.  
And again, I suspect most of these sorts of documents are more likely to 
flow to the ISE or perhaps a future IRTF RG.  As the current ISE, that 
is a burden I would gladly bear, because there is the opportunity to 
help the Internet community, including the IETF and ICANN.


I also have no problem rejecting trivial or bad proposals.

Eliot




OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop