Subject: URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jan 2020 01:57:32 -0500

Hi.

My apologies for the extreme lateness of this note.  I have
tried to pass URN work on to others since RFCs 8141 and 8254 and
had assumed that someone else would check through this document
to be sure that it appropriately covered both locator-type and
name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3).
I had assumed that reviews within the ART area and/or a specific
ART Area Review would address that topic but, AFAICT, they may
not have done so.

I've had occasion to look through the document and I'm actually
not sure about the name-locator distinction as it may apply to
it.  This note will be short and is rather more about asking the
IESG to be sure that any possible issues are addressed than to
try to do a detailed review of the issues.

AFAICT, the focus of the I-D is to be sure that applications and
elaborations of any URI scheme be firmly under the control and
management of the owner of that scheme and that possible
deviations from that principle are well-controlled.
http://www.w3.org/TR/2004/REC-webarch-20041215, Section 2.2.2.1,
cited in the draft as [webarch] is clear that the ownership of a
URN is delegated to the owners of URN Namespaces rather than
being bound to the "urn" URI scheme itself.  I believe it is
possible to read this document in a way that has no impact on
URNs and URN namespaces.   However, it appears to me that, if
read without appropriate care, some of the restrictions imposed
on queries and fragments may be inconsistent with mechanisms and
syntax for use in particular URN Namespaces or URNs generally
that were contemplated and extensively discussed during the
development of RFC 8141.  Those ideas were deferred by the WG
for future work but the mechanisms may well be in use in
important URN namespaces.  Because the last paragraph of Section
1.1 of this I-D essentially declares any existing specification,
even a standards-track one or one adopted by other bodies, that
does not comply with the recommendations of the I-D to be
incorrect and in need of correction, the effects of a reading
that retroactively restricts URN Namespace practices that are
under the control of the Namespace owners could be quite serious.

My preference would be that someone who has been more active
with URN work and Namespace registrations in the last couple of
years do a careful review of the document to determine whether
my concerns justify some tuning of the text.  However, given how
late it is in the review process (again, my apologies for not
catching the issue until now), a reasonable alternative would be
to simply insert a sentence early in the I-D that says that it
applies primarily to locator-type URIs although name-type ones
may find it useful as general guidance _or_ to explicitly call
out the difference in ownership between URNs and other URI
schemes.

 thanks,
   john

p.s. It would be, IMO, helpful if the IESG and the community
would think about the implications of BCP (or IETF-stream
Informational) documents that effectively obsolete or deprecate
existing standards without identifying them or explicitly
updating them and whose responsibility it is to find the
discrepancies.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Jan 2020 08:51:00 -0500

I remain of the view that the URN/URL distinction is unhelpful because it
is meaningless. There are no sharp boundaries between categories of
identifier as the distinction supposes.

Before making this argument in more detail, I will make a plea for respect.
I find that the biggest obstacle to getting clarity on naming is that when
faced with an analysis that contradicts deeply held beliefs, the usual
response is to tell people to 'do some research' or 'understand the issues'.

The URN/URI distinction does not in fact represent an essential distinction
between types identifiers as claimed. It describes a difference in source
of authority at best, not an essential property.

1) DNS names are names.

This is easy to see, it is what the N stands for. The signifier bears no
direct relation to the signified. It is a purely conventional relationship.

2) IP addresses are also names

Again, the signifier bears no direct relation to the signified. It is a
purely conventional relationship.

3) File names are names

Again, the signifier bears no direct relation to the signified. It is a
purely conventional relationship.

4) HTTP local paths are names

See above.

So a HTTP URL consists of

<method part> :// <IANA name part> // <local name part>

So a URL is obviously a form of name. The location semantics are not
intrinsic to the name itself, they are intrinsic to its mode of use.

If you look at practically every UR'N' scheme it has precisely the same
form albeit with different syntax. There is a method part and some
hierarchical delegation of naming. But (with rare exceptions) it is naming
all the way down.

The reason URL/URL discussions are so notoriously unproductive is people
are attempting to make an intrinsic distinction between classes of name
where there is none.

The only forms of network identifier that are not pure names are data URIs
and the ones that are indexical such as the ni: scheme described in RFC6920.

But even that distinction can be bent. The strong Internet Names I propose
here:
https://www.ietf.org/id/draft-hallambaker-mesh-udf-08.html define a subset
of DNS labels that are indexical rather than names. And those have some
important and useful properties. They allow the result of a trust decision
to be encapsulated as an atomic name.

On Tue, Jan 7, 2020 at 1:58 AM John C Klensin <[email-masked]> wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jan 2020 11:15:42 -0500

Phillip Hallam-Baker <[email-masked]> wrote:
    > I remain of the view that the URN/URL distinction is unhelpful because it is
    > meaningless. There are no sharp boundaries between categories of identifier
    > as the distinction supposes.

    > Before making this argument in more detail, I will make a plea for respect. I
    > find that the biggest obstacle to getting clarity on naming is that when

    > between types identifiers as claimed. It describes a difference in source of
    > authority at best, not an essential property.

I agree with you.

I think that we might have found new ways in which they are meaningfully
distinct had to a uquitious way to resolve the more abstract URNs.
That didn't happen, and I don't imagine that it is coming in the way envisioned.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Adam Roach <[email-masked]>
Date: Tue, 7 Jan 2020 10:35:09 -0600

To help with framing this conversation, the changes from RFC 7320 are 
highlighted here:

https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingham-rfc7320bis-03

I have some rather extensive thoughts on the process of creating bis 
documents [1]. While I'm not going to reiterate all of them here, I want 
to highlight a specific passage that seems to bear on John's comments:

>    One major concern that drives these incremental document updates is
>    that an attempt to republish an RFC as originally described in RFC
>    2026 can result in such an effort being bogged down by issues that
>    exist in text unrelated to the desired changes.  Such issues can
>    arise from a change in the consensus of the IETF around best current
>    practices, such as in the areas of security, privacy, or
>    architectural design of an underlying protocol.  This complication
>    arises from the fact that processing of an updated full version of an
>    RFC is procedurally identical to processing of a green-field
>    definition of a new protocol: review by the IETF at large, and review
>    by the IESG, are performed on the entire document, leaving legacy
>    text open to comments that will delay - and occasionally block -
>    publication of such documents.

/a

____
[1] https://tools.ietf.org/html/draft-roach-bis-documents-00

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Jan 2020 12:48:02 -0500

I think we need to tease apart two things in John's note: the URN
scheme, and the concept of URNs as opposed to URLs, the two together
forming what we call URIs.

It's clear to me that BCP 190 has no actual effect on "urn:", because
the things it talks about simply don't apply there, or are taken care
of by the fact that URN namespaces are completely controlled by the
owners of the namespaces.  There is no internal hierarchy within URN
namespaces unless the specification of the namespace creates one and
defines how that hierarchy works and is managed.

For the other part of the issue, I'm not fully in agreement with
Phillip and Michael, in that I do think there's a useful distinction
between a URI that names something without specifying how to locate
it... and one that is a locator.  There is, for example, a fundamental
difference between, say, "http:" and "ni:" (see RFC 6920).

That said, I also think that existing URI schemes that define *names*
lack hierarchies, and are similarly not really affected by BCP 190.
As I read through 7320bis and placed my "Yes" ballot, I didn't see
anything, neither in the original text nor in the changed text, that
made me question this, and as I look back through it now I still
don't.

So I don't have any concerns here.  If anyone has something specific
to raise, please raise it now, while the document is still in IESG
Evaluation and we can more easily discuss it and make changes.

Barry

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jan 2020 14:11:40 -0500

--On Tuesday, January 7, 2020 10:35 -0600 Adam Roach
<[email-masked]> wrote:

> To help with framing this conversation, the changes from RFC
> 7320 are highlighted here:
> 
> I have some rather extensive thoughts on the process of
> creating bis documents [1]. While I'm not going to reiterate
> all of them here, I want to highlight a specific passage that
> seems to bear on John's comments:
> 
>>    One major concern that drives these incremental document
>> updates is    that an attempt to republish an RFC as
>> originally described in RFC    2026 can result in such an
>> effort being bogged down by issues that    exist in text
>> unrelated to the desired changes.  Such issues can   
>> arise from a change in the consensus of the IETF around best
>...

Adam,

I studied those comments when you first posted them.  I believe
that I sent comments at that time, but to summarize and
highlight them in a shorter note, I see a key problem (and
several others that may be less important and that were
addressed in my earlier comments) with an replacement document
that does not address all open issues in its predecessor:

It leaves the reader with the understanding that the new
document represents the IETF's best understanding of the topic
covered (not merely a view of the most urgent problems to be
fixed).  Put differently, it implies that any issues not address
are unimportant.   That can be mitigated somewhat by including a
section identifying known outstanding issues, but
draft-nottingham-rfc7320bis-03 does not appear to contain such a
section. 

In addition, as your quoted comment above implies, an
incremental document that nonetheless replaces an earlier one is
a change to what 2026 specifies.  I do not believe it is
appropriate to change the procedures of 2026 by ignoring it, nor
do I believe that examples of its being ignored in the past
constitute justification for ignoring it in the future.  Just as
we tried to do with NEWTRK and ISDs (arguably a different
approach to at least part of the problem you are trying to
address), a change to how we handle replacement documents that
ignores (if nothing else) 2026's "no known defects" rule
requires an update or other change to 2026 before the desired
approach is appealed to in order to justify a particular
document.

That, and my p.s., aside, I had hoped my note would rather
carefully avoid dragging us back into either this issue or the
ones raised by Phillip and Barry (like Barry, I don't fully
agree with the former).  It seems to me that both that comment
and part of Barry's raise fundamental questions about how
RFC3986 is defined and what it specifies.  Those issues are
probably best addressed at another time.  

Instead, I was trying to raise a far more narrow question: Given
that RFC 3986 separates names and locators and that we have
already had confusion about what is appropriate in URNs based on
the language there, does this document make things worse?  I
think it may.  Even a statement fragment (from the first
paragraph of Section 3 and inherited from 7320) like "...as
links that are exchanged as part of the protocol, rather than
statically specified syntax" are inconsistent with the use of
keyword values in some URN namespaces as static indicators.  If
you want to ask the slightly different question of whether, if
RFC 7320 made things worse, does this I-D make things even worse
than that, I don't have an easy answer except to note at least
one example: The last paragraph of Section 2.3, which appears to
be new, says

> Extensions MUST NOT define a structure within individual URI
> components (e.g., a prefix or suffix), again to avoid
> collisions and erroneous client assumptions.

But, as I understand that rule, it is precisely what some rules,
and provisions for namespace-specific rules, in RFC 8141, do.

Again, the solution at this point appears to be either to be
much more careful about binding the statements in the I-D to the
concept of ownership or to indication that this specification
does not apply to URNs (or, if preferred, to what 3986 describes
as "name" URIs) at all.

best,
   john

---

From: Keith Moore <[email-masked]>
Date: Tue, 7 Jan 2020 14:23:16 -0500

On 1/7/20 12:48 PM, Barry Leiba wrote:

> it... and one that is a locator.

I emphatically disagree.  URNs have /defined/ properties that URIs in 
general do not.   The constant efforts by those politically opposed to 
URNs because of Not Invented Here syndrome, to degrade the utility of 
URNs, have been obvious for a long time now, and can only be understood 
as deliberate efforts to cause harm.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Jan 2020 14:53:43 -0500

> difference between, say, "http:" and "ni:" (see RFC 6920).

That is precisely what I was talking about when I said that ni: is
indexical. But that is no longer an essential distinction either.

We can distinguish names that are under IANA authority (DNS, IP) from those
that are not. But that is the limit of it.

Given that it was announced today that SHA-1 was broken, lets take another
look at a SIN:

[email-masked]

That is a valid email address. It can be routed on the Internet (not the
best privacy choice but possible). But it is a name that can be bound to a
security policy.

So if  mb2gk-6duf5-ygyyl-jny5e-rwshz is the UDF (SHA-2-512) of Alice's
OpenPGP encryption key. We have an implicit semantic here: Encrypt all mail
sent to this address with the key that has fingerprint
mb2gk-6duf5-ygyyl-jny5e-rwshz

The reason that I have hammered on the fact that the name/locator
distinction being bogus is precisely because the obsession with defining a
distinction where there is NO difference has caused the neglect of a
situation where there is a very real and important one.

https://www.ietf.org/id/draft-hallambaker-mesh-udf-08.html#name-secure-internet-names

A Strong Internet Name allows ANY URI with a DNS component to be turned

> That didn't happen, and I don't imagine that it is coming in the way

HTTPs are names but they are a name that embodies a (fairly) unambiguous
means of location.

Having had the misfortune to engage in discussion with acolytes of a
prominent opponent of post-modernism, I have been writing a defense of
postmodernism today. One of the chief arguments made by the postmodernists
is that perfect knowledge is an illusion. And I think that is a profound
observation that is essential to understanding why the original concept of
URNs and for that matter most registration schemes are doomed to fail.

The Web succeeded because of 404 Not Found. The links are scruffy. And that
is fine if you are OK with the idea that knowledge can be scruffy, that it
will never be perfect. And that is why the Web came out of CERN because
(good) scientists understand that there is no absolute knowledge and that
what we are arriving at is a better approximation to the truth, not the
truth itself.

There have been plenty of people making that type of argument since ancient
times. But until the mid 80s, most scientists had a very rigid epistemology
that was essentially Victorian in its outlook. Scientists were serious
people who were finding out profound and universal truths and we had all be
very very careful not to make mistakes because that 'would be bad'.

I would encourage people to take a look at what research scientists in
their 20s and 30s are saying about their approach to science. They are
utterly rejecting that view.

What politicians now call 'Western values' and demand other countries
observe is a modern construct that is fifty years (racial tolerance) old at
most. In some areas, what is now the fixed consensus is less than a decade
old (evolve already). The reason we have the nonsense of .com, .org, .net
etc is because DNS was designed by people who had an essentially Victorian
view of epistemology in which taxonomy represents essential qualities.
(Whether the same is true of the extension TLDs I will leave aside)

The reason I and others received (and continue to receive from some) the
patronizing responses we do (do some research you ignorant baboon! you
don't understand) is that we have profoundly different and fundamentally
incompatible epistemologies and some people regard mine as heresy. Both are
capable of self examination. But mine is capable of examining theirs, they
can only reject mine. So its like me trying to explain complex numbers to
someone who insists that you can't take the square root of a negative
number and can't get past that.

The route out of formal methods to PoMo is that to solve the problems we
faced in the 1980s in formal methods, it was necessary to apply
meta-mathematics and understand the limitations of logic. And once you do
that you are in Post Modernism.

So the URN notion that we must carefully decide how to resolve before we
defined schemes was wrong. It was and is much more important to have a
catalog that is as *complete *as possible than for the entries to be
*correct*.

Resolution of many types of name is inherently ambiguous because the
context varies. We cannot resolve a barcode on a physical object like a can
of beans. But we can ask for information on the can of beans and we can
order an instance of the can of beans for delivery. And both forms of
'location' are going to be subjective and depend on the context in which
they are attempted.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jan 2020 16:33:31 -0500

Keith Moore <[email-masked]> wrote:
    > I emphatically disagree. URNs have defined properties that URIs in general do
    > not. The constant efforts by those politically opposed to URNs because of Not
    > Invented Here syndrome, to degrade the utility of URNs, have been obvious for
    > a long time now, and can only be understood as deliberate efforts to cause
    > harm.

I really wanted URNs to succeed.

I have not seen this occur.  Either that's because they are too hard to use,
or there isn't any compelling reason to use them. I don't know which.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 7 Jan 2020 14:36:23 -0700

On 1/7/20 2:33 PM, Michael Richardson wrote:
> I have not seen this occur. 

Definitions of success vary. URNs are widely used in the information
sciences (e.g., national libraries), but that isn't as visible as the web.

Peter

---

From: Keith Moore <[email-masked]>
Date: Tue, 7 Jan 2020 16:47:33 -0500

On 1/7/20 4:33 PM, Michael Richardson wrote:

> Keith Moore<[email-masked]>  wrote:

There have also been efforts to sabotage them.  URNs were always seen as 
competing with handles and later DoIs, and some people didn't like 
that.   And the very idea that IETF would create a new namespace 
distinct from URLs, also rankled some who saw it an intrusion on their 
own architecture.

But I suspect that the biggest problem that URNs have had is that they 
aren't well understood, even within IETF.

Keith

---

From: Christian <[email-masked]>
Date: Tue, 7 Jan 2020 22:49:29 +0000

picking up as a post modern fag end...

On 07/01/2020 19:53, Phillip Hallam-Baker wrote:
> context varies.. We cannot resolve a barcode on a physical object like 
> a can of beans. But we can ask for information on the can of beans and 
> we can order an instance of the can of beans for delivery. And both 
> forms of 'location' are going to be subjective and depend on the 
> context in which they are attempted.

I suppose the question is can a schema capture both identifier and 
locator contexts (my plural) unambiguously in all cases?

Should I take your post modernist interpretation as saying the answer is 
no - we have to live with ambiguity, even to the extent of the failure 
to resolve one or other or possibly both and do so without breaking wind?

But given this interpretation what language is needed if URI and URN 
linguistically don't meet the need?

Or is the other interpretation to offer a list of contexts that work and 
exclude application for the others?

In which case which is the more useful approach for building real world 
apps and their networks?

It rather kills the idea of hard coded registries for all eventualities 
I think. That I like. As I really like the import of post modernist 
sensibility. This argument is worth something.

best Christian

---

From: Larry Masinter <[email-masked]>
Date: Tue, 7 Jan 2020 15:50:43 -0800

FWIW, while I agree with the "spirit of  making this BCP guidance, 
rather than rules", I don't see how changing "MAY" to "can"
or a "SHOULD NOT... but instead" to "are encouraged to"
is helpful (substituting terms that are well-defined with
words that seem to be similar in meaning but less well-defined.

The keywords MAY, SHOULD, SHOULD NOT seem to me
to be sufficient "guidance" in a BCP-status document.

Perhaps it would be helpful to add  a kind of applicability statement at the
beginning that these guidelines are intended to apply to
"http:" and "https:" URIs and those  with similar patterns
and SHOULD be considered for others, although they don't
 seem to be relevant for URI-schemes that don't use the generic syntax
with hierarchical paths  (such as "urn:" or "data:" or "mailto")

There is no need to consider the philosophic difference
between a name and a locator.

It's a matter of choosing a syntax for serialization of
a data structure and the implication of ownership
 and origin that comes with some syntactic arrangements
for some implementations.

Larry
-- 
https://LarryMasinter.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Jan 2020 19:18:31 -0500

On Tue, Jan 7, 2020 at 5:49 PM Christian <[email-masked]> wrote:

> context varies.. We cannot resolve a barcode on a physical object like a
> can of beans. But we can ask for information on the can of beans and we can
> I suppose the question is can a schema capture both identifier and locator
> contexts (my plural) unambiguously in all cases?
>
Definitely not because the identifier interpretation can change over time.
Additional contexts can be added. The identifier may be grandfathered into
a new scheme. It may be abandoned.

> no - we have to live with ambiguity, even to the extent of the failure to
> resolve one or other or possibly both and do so without breaking wind?
>
We can deny that the ambiguity exists. We can say the earth is flat as
well. But it won't change anything.

> In which case which is the more useful approach for building real world
I believe that the Internet was founded on the principle of allowing every
user to experiment and to extend. It is thus impossible to enumerate all
possible uses. It is however possible to identify uses that are useful
generally and network effects strongly (unfortunately too strongly)
encourage focusing on common uses.

> It rather kills the idea of hard coded registries for all eventualities I
> think. That I like. As I really like the import of post modernist

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 7 Jan 2020 17:31:00 -0700

On 1/7/20 12:11 PM, John C Klensin wrote:

> keyword values in some URN namespaces as static indicators. 

Indeed, it's not immediately obvious what a "protocol" would be in the
case of many URN namespaces, precisely because the URN is a name rather
than a locator.

> If

It's not clear to me whether a URN namespace counts as a 7320bis
protocol extension (which can "offer new capabilities that could apply
to any identifier, or to a large subset of possible identifiers");
however a definition of, say, URN r-components would probably fit the
bill, and such a definition might well define structures that would
violate the aforementioned MUST NOT.

> does not apply to URNs (or, if preferred, to what 3986 describes

That might be the best approach.

Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Jan 2020 00:48:05 +0000

Or you are looking in the wrong place.  Library/information sciences?

---

From: Rob Sayre <[email-masked]>
Date: Tue, 7 Jan 2020 17:41:38 -0800

> sciences (e.g., national libraries), but that isn't as visible as the web.

Definitions of success do indeed vary. Without weighing in on this
particular issue, the IETF does seem to be clinging to unsuccessful
standards like URNs and DNSSEC. That doesn't mean they're bad, but it does
mean those standards missed the mark in ways that would have been difficult
to predict at the time they were drafted. This failure to reflect is
disappointing.

thanks,
Rob

---

From: Keith Moore <[email-masked]>
Date: Tue, 7 Jan 2020 21:21:35 -0500

On 1/7/20 8:41 PM, Rob Sayre wrote:

> standards like URNs and DNSSEC. That doesn't mean they're bad, but it 
> does mean those standards missed the mark in ways that would have been 
> difficult to predict at the time they were drafted. This failure to 
> reflect is disappointing.

Actually, it means no such thing.

For URNs, the average Internet user or even IETF participant simply is 
not in a position to evaluate their utility.   Granted, the expectation 
within IETF was that URNs would be more publicly visible than they are 
now.   But most people don't know what ISBNs are either, and they've 
been around much longer.

(I expect that URNs would be much more visible to us today had URN 
resolution systems been developed and incorporated into browsers.   But 
this is still possible.   Meanwhile, URNs remain useful even without URN 
resolution support in browsers, just not as widely useful and not as 
visible.)

DNSSEC is still quite useful, even though it has had a bit of trouble 
getting going.   The very nature of DNSSEC was that it would take a long 
time to deploy.   A similar statement could be made (and has been made) 
about IPv6.

It's very shortsighted to expect that everything that IETF does that is 
useful, will appear useful to IETF participants within a few years of 
adoption.

I realize that much of the industry has come to expect quick payoff.   
Reality is that some good things take time to mature before they're 
useful.  Fortunately, IETF isn't a VC-funded startup that needs to ship 
product within two years.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 7 Jan 2020 21:36:11 -0500

> On Jan 7, 2020, at 9:21 PM, Keith Moore <[email-masked]> wrote:
> 
> DNSSEC is still quite useful, even though it has had a bit of trouble getting going.   The very nature of DNSSEC was that it would take a long time to deploy.   A similar statement could be made (and has been made) about IPv6.
> 
> It's very shortsighted to expect that everything that IETF does that is useful, will appear useful to IETF participants within a few years of adoption.

Indeed, and 2019 saw a significant uptick in the number of DNSSEC domains,

  https://stats.dnssec-tools.org/images/totalds.svg

For a few additional data points:

  https://lists.dns-oarc.net/pipermail/dns-operations/2020-January/019559.html

  - 10.70 million signed delegations, up from ~8.77 million a year ago.
    + 1.50 million signed .COM delegations, up from ~973 thousand.
    + 97 TLDs with 1000+ signed delegations, up from 76.

  - 1.73 million DANE SMTP domains, up from ~775 thousand a year ago.
    + DANE MX hosts in 5.0 thousand zones, up from ~3.8 thousand.

  - ECDSA P256 (13) now most common KSK algorithm, ahead of RSASHA256 (8).
    + Last year: 4,005,976 alg 8; 1,908,218 alg 13.
    + This year: 3,798,256 alg 8; 3,937,115 alg 13.

Also, for example, the .com and .net zone ZSKs have been upgraded from
1024-bit RSA to 1280-bit RSA.

Meaningful progress is being made.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Jan 2020 00:08:34 -0500

--On Tuesday, January 7, 2020 17:31 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> RFC 7320 made things worse, does this I-D make things even
>> worse than that, I don't have an easy answer except to note
>> at least one example: The last paragraph of Section 2.3,
>> which appears to be new, says
>> 
>> But, as I understand that rule, it is precisely what some
>> rules, and provisions for namespace-specific rules, in RFC
>> 8141, do.
> 
> It's not clear to me whether a URN namespace counts as a
> 7320bis protocol extension (which can "offer new capabilities
> that could apply to any identifier, or to a large subset of
> possible identifiers"); however a definition of, say, URN
> r-components would probably fit the bill, and such a
> definition might well define structures that would violate the
> aforementioned MUST NOT.

I was trying to avoid getting dragged down into details, both in
the hope of keeping the message as short as possible and to
avoid a distracting side-discussion, but, yes r-components and
the issues associated with pass-through information for those
URN namespaces that resolve to one or more URLs were examples
that crossed my mind.

>> much more careful about binding the statements in the I-D to
>> the concept of ownership or to indication that this
>> specification does not apply to URNs (or, if preferred, to
>> what 3986 describes as "name" URIs) at all.
> 

If we don't want both the discussion and the document to drag
out, I believe so.

best,
   john

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Jan 2020 22:31:00 -0800

> Actually, it means no such thing.

Check out the footnote in

https://www.iab.org/documents/correspondence-reports-documents/2019-2/avoiding-unintended-harm-to-internet-infrastructure/

At the very least, one might concede that the usefulness of DNSSEC is a
matter of debate.

I actually happen to think DNSSEC might be useful once DNS transports are
encrypted, which the IETF has screwed up for 30 years. However, the DNSSEC
RFC is 15 years old, so I don't think it's generally productive to bring up
in new work.

thanks,
Rob

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Jan 2020 02:13:32 -0500

> At the very least, one might concede that the usefulness of DNSSEC is a

There is no debating that some find it useful.  Their use-cases
(priorities) may be different from yours.  That is, there's nothing to
debate.

> RFC is 15 years old, so I don't think it's generally productive to bring up

The base insecure DNS, SMTP, TCP are older still, and we continue to use
them and build on them.  There's no meat on this bone of contention, and
it is in any case a digression.  Let's move on.

-- 
    Viktor.