Re: [DNSOP] Dealing with some open Errata:

[Warren Kumari]

Whoops, apologies, the previous reply was in my Drafts and I hit send on
the wrong version. 

I will ask the IANA to update the reference to be RFC4340, and include a
link to this thread.

W




On Mon, Jan 29, 2024 at 1:27 PM, Warren Kumari  wrote:

> On Mon, Jan 15, 2024 at 7:51 PM, John Levine  wrote:
>
>> It appears that Paul Wouters  said:
>>
>> Section 4.1.2. says:
>>   | URI| _dccp | [RFC7566] |
>>
>> I think this might have been part of a list used to "reserve" the names
>> of (transport) protocols, so that constructs like _25._quic.example.com
>> could be constructed where the _name denotes the protocol and not the name
>> of something. I think dccp got added to this list because it is references
>> as a "transport protocol" in RFC4340 and the author wanted to make sure
>> transport protocol names were not accidentally squatted by newly invented
>> things with a clashing name/acronym.
>>
>> I think I'm the one who added it and that was definitely the idea. You
>> should be able to use SRV or URI with any transport protocol so in view of
>> the modest set of transport protocols in use, we might as well reserve
>> their names. Dunno where that RFC number came from, though.
>>
>
>
> Okey donkey —I think that the best outcome then is to do what Dave
> suggested above — "leave the registration but take out the reference.".
>
> I'd love to be able to ask IANA to make the reference be "Because, well,
> we felt like it….",  but I'm trying to at least pretend to be a grownup, so
> I won't…
>
> W
>
>
>
>> R's,
>> John
>>
>> ___
>> 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] Dealing with some open Errata:

[Warren Kumari]

On Mon, Jan 15, 2024 at 7:51 PM, John Levine  wrote:

> It appears that Paul Wouters  said:
>
> Section 4.1.2. says:
>   | URI| _dccp | [RFC7566] |
>
> I think this might have been part of a list used to "reserve" the names of
> (transport) protocols, so that constructs like _25._quic.example.com
> could be constructed where the _name denotes the protocol and not the name
> of something. I think dccp got added to this list because it is references
> as a "transport protocol" in RFC4340 and the author wanted to make sure
> transport protocol names were not accidentally squatted by newly invented
> things with a clashing name/acronym.
>
> I think I'm the one who added it and that was definitely the idea. You
> should be able to use SRV or URI with any transport protocol so in view of
> the modest set of transport protocols in use, we might as well reserve
> their names. Dunno where that RFC number came from, though.
>


Okey donkey —I think that the best outcome then is to do what Dave
suggested above — "leave the registration but take out the reference.".

I'd love to be able to ask IANA to make the reference be "Because, well, we
felt like it….",  but I'm trying to at least pretend to be a grownup, so I
won't…

W



> R's,
> John
>
> ___
> 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] Dealing with some open Errata:

[John Levine]

It appears that Paul Wouters   said:
>> Section 4.1.2. says:
>>   | URI    | _dccp | [RFC7566] |

>I think this might have been part of a list used to "reserve" the names
>of (transport) protocols, so that constructs like _25._quic.example.com
>could be constructed where the _name denotes the protocol and not the
>name of something. I think dccp got added to this list because it is
>references as a "transport protocol" in RFC4340 and the author wanted
>to make sure transport protocol names were not accidentally squatted
>by newly invented things with a clashing name/acronym.

I think I'm the one who added it and that was definitely the idea. You
should be able to use SRV or URI with any transport protocol so in
view of the modest set of transport protocols in use, we might as well
reserve their names. Dunno where that RFC number came from, though.

R's,
John

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

Re: [DNSOP] Dealing with some open Errata:

[Dave Crocker]

On 1/15/2024 2:49 PM, Paul Wouters wrote:

I think this might have been part of a list used to "reserve" the names
of (transport) protocols, so that constructs like _25._quic.example.com
could be constructed where the _name denotes the protocol and not the
name of something. I think dccp got added to this list because it is
references as a "transport protocol" in RFC4340 and the author wanted
to make sure transport protocol names were not accidentally squatted
by newly invented things with a clashing name/acronym. 


That's a rather more thoughtful and pleasing explanation.  I think it is 
also correct.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [DNSOP] Dealing with some open Errata:

[Dave Crocker]

On 1/15/2024 2:20 PM, Warren Kumari wrote:
These include two Errata filed by Bernie Hoeneisen (author of RFC6118) 
against RFC8552 - "Scoped Interpretation of DNS Resource Records 
through "Underscored" Naming of Attribute Leaves" 



I'd like to get feedback by Monday Jan 29th, otherwise I'll just go 
with my proposed resolutions below.




Errata1: https://www.rfc-editor.org/errata/eid7066
---
Section 4.1.2. says:
  | URI    | _dccp | [RFC7566] |

It should say:
?

Notes:
Wrong reference. RFC7566 does not even mention "dccp". Unaware of a 
useful reference. Not sure this line needs to be removed.


Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

—-

I **think** that the correct reference for this is actually RFC7553 - 
"The Uniform Resource Identifier (URI) DNS Resource Record" 
. Note that this initially 
confused me, because I was looking for DCCP (and TCP and UDP) in the 
URI *registry*, not in the DNS RR definition.



My proposed resolution: Mark Errata verified, update reference to be 
RFC7553.


I am not finding the string dccp in rfc7553.

I looked in the other candidate RFCs and didn't find _dccp in them.

Absent affirmative knowledge that this _attribute is in real-world use, 
the correct action would be to remove it from the registry, IMO.


In the alternative -- since it is not exactly damaging or wasting a 
precious resource -- leave the registration but take out the reference.  
So it shows as registered, but implies it is there because, well, we 
felt like it.


On reflection, quite a few of the entries were, I think, done for 
exactly that reason.  Or rather, for completeness.  Note, for example, 
that the SRV registration for _dccp points to the SRV RR definition, 
although that document does not cite dccp.





Errata 2: https://www.rfc-editor.org/errata/eid7068:
—-
Section 4.1.2. says:
  | URI    | _tcp  | [RFC6118] |
  | URI    | _udp  | [RFC6118] |

It should say:
?

Notes:
Wrong reference. RFC6118 does not even mention "tcp" nor "udp". 
Unaware of useful reference(s). Not sure this line needs to be removed.


Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

---


My proposed resolution: Same as above.

I think that these, two, were cases of wanting completeness in the 
registrations.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dealing with some open Errata:

[Paul Wouters]

On Mon, 15 Jan 2024, Warren Kumari wrote:


Subject: [DNSOP] Dealing with some open Errata:

[ + Dave Crocker (author), Paul Wouters, Frederico Neves (registry experts)] 

Hi there all,

As part of the Great Errata Cleanup of 2024, I'm going through reported Errata 
and trying to close them. 
I'm just dealing with the ones that I can do myself, but there are some which I 
need WG input on.

These include two Errata filed by Bernie Hoeneisen (author of RFC6118) against 
RFC8552 - "Scoped Interpretation of DNS Resource Records through
"Underscored" Naming of Attribute Leaves"

I'd like to get feedback by Monday Jan 29th, otherwise I'll just go with my 
proposed resolutions below. 



Errata1: https://www.rfc-editor.org/errata/eid7066
---
Section 4.1.2. says:
  | URI    | _dccp | [RFC7566] |

It should say:
?

Notes:
Wrong reference. RFC7566 does not even mention "dccp". Unaware of a useful 
reference. Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
—-

I **think** that the correct reference for this is actually RFC7553 - "The Uniform 
Resource Identifier (URI) DNS Resource Record". Note that
this initially confused me, because I was looking for DCCP (and TCP and UDP) in 
the URI *registry*, not in the DNS RR definition.


I think this might have been part of a list used to "reserve" the names
of (transport) protocols, so that constructs like _25._quic.example.com
could be constructed where the _name denotes the protocol and not the
name of something. I think dccp got added to this list because it is
references as a "transport protocol" in RFC4340 and the author wanted
to make sure transport protocol names were not accidentally squatted
by newly invented things with a clashing name/acronym.


My proposed resolution: Mark Errata verified, update reference to be RFC7553. 


I would update the reference to 4340.


Errata 2: https://www.rfc-editor.org/errata/eid7068:
—-
Section 4.1.2. says:
  | URI    | _tcp  | [RFC6118] |
  | URI    | _udp  | [RFC6118] |

It should say:
?

Notes:
Wrong reference. RFC6118 does not even mention "tcp" nor "udp". Unaware of 
useful reference(s). Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
--- 


My proposed resolution: Same as above. 


I believe these should be fixed to RFC7553:

See: https://datatracker.ietf.org/doc/html/rfc7553#section-4.1

   As another example, suppose we are looking for the URI for a service
   with Service Name "A" and Transport Protocol "B" for host
   example.com.  Then we would query for
   (QNAME,QTYPE)=("_A._B.example.com","URI").

eg: _smtp._tcp.example.com IN URI 

As a Delegated Expert, if someone wants a new entry in this IANA
registry, I look for clashes with existing transport protocols
and would probably reject it if I find such a clash.

Paul

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