Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-26 Thread Mats Dufberg
I prefer a regex and I think that Dave's "_ta-.*" makes most sense. An 
explanation that it is a regex and that the exact format of the name is found 
in RFC 8145 is needed.


Mats

---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/
 

On 2018-07-25, 21:58, "DNSOP on behalf of John Levine"  wrote:

In article <9ac469b7-031a-4d8c-53d0-a82abca0d...@dcrocker.net>,
Dave Crocker   wrote:
>On 7/25/2018 10:59 AM, Bob Harold wrote:
>> Dot "." has special meaning in DNS, so I would prefer:
>> 
>>  Â Â  _ta-*
>> 
>> Not regex, but a common wildcard usage.
>
>wfm.

I suppose.  A plausible actual regex would be

   _ta(-[0-9a-z]{4}){1,12}

which might be a bit dense.  That's not quite right because the
numbers in the label have to be sorted, but there's no way to say that
in a regex other than enumerating them which would be bulky.

Whatever you do, please put include some text reminding people that it's
a conceptual glob stype wildcard, not a DNS wildcard.

R's,
John
-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for 
Dummies",
Please consider the environment before reading this e-mail. https://jl.ly



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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread John Levine
In article <9ac469b7-031a-4d8c-53d0-a82abca0d...@dcrocker.net>,
Dave Crocker   wrote:
>On 7/25/2018 10:59 AM, Bob Harold wrote:
>> Dot "." has special meaning in DNS, so I would prefer:
>> 
>>     _ta-*
>> 
>> Not regex, but a common wildcard usage.
>
>wfm.

I suppose.  A plausible actual regex would be

   _ta(-[0-9a-z]{4}){1,12}

which might be a bit dense.  That's not quite right because the
numbers in the label have to be sorted, but there's no way to say that
in a regex other than enumerating them which would be bulky.

Whatever you do, please put include some text reminding people that it's
a conceptual glob stype wildcard, not a DNS wildcard.

R's,
John
-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread Tim Wicinski
I like Bob's suggestion.

On Wed, Jul 25, 2018 at 2:06 PM, Dave Crocker  wrote:

> On 7/25/2018 10:59 AM, Bob Harold wrote:
>
>> Dot "." has special meaning in DNS, so I would prefer:
>>
>> _ta-*
>>
>> Not regex, but a common wildcard usage.
>>
>
> wfm.
>
> anyone else care to chime in?
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> ___
> 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] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread Dave Crocker

On 7/25/2018 10:59 AM, Bob Harold wrote:

Dot "." has special meaning in DNS, so I would prefer:

    _ta-*

Not regex, but a common wildcard usage.


wfm.

anyone else care to chime in?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread Dave Crocker

On 7/25/2018 10:59 AM, Bob Harold wrote:

Dot "." has special meaning in DNS, so I would prefer:

    _ta-*

Not regex, but a common wildcard usage.


wfm.

anyone else care to chime in?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread Bob Harold
On Wed, Jul 25, 2018 at 1:50 PM Dave Crocker  wrote:

> On 7/25/2018 2:32 AM, Mats Dufberg wrote:
> > _ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf.
>
>
> Wow. This is a unique case, since it reserves essentially all of an
> even-more-subordinate namespace -- everything to the right of that dash.
>
> Theoretically it isn't that inclusive but in practical terms, unless we
> want complex pattern-matching for sub-strings at run-time, it is.
>
> I'm inclined to have the notation be:
>
>  _ta-.*
>
> to draw from regex, with an explicit reference to that, unless folks
> agree on something else.  (Yes, that's 'pattern matching' but it's in
> the specification document, not the operational code.)
>
> Thoughts?
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>

Dot "." has special meaning in DNS, so I would prefer:

   _ta-*

Not regex, but a common wildcard usage.

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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread Dave Crocker

On 7/25/2018 2:32 AM, Mats Dufberg wrote:

_ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf.



Wow. This is a unique case, since it reserves essentially all of an 
even-more-subordinate namespace -- everything to the right of that dash.


Theoretically it isn't that inclusive but in practical terms, unless we 
want complex pattern-matching for sub-strings at run-time, it is.


I'm inclined to have the notation be:

_ta-.*

to draw from regex, with an explicit reference to that, unless folks 
agree on something else.  (Yes, that's 'pattern matching' but it's in 
the specification document, not the operational code.)


Thoughts?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread Dave Crocker

On 7/25/2018 6:25 AM, Tim Wicinski wrote:
/no/ changes to the spec, except to correct the typo Bob Harold spotted. 
   Correct?



darn.  i was trying to be clear that the note referred only to that 
specific exchange.


the . typo is fixed.

I'm also adding the other underscored names folks have been citing.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread Tim Wicinski
/no/ changes to the spec, except to correct the typo Bob Harold spotted.
Correct?



On Wed, Jul 25, 2018 at 9:23 AM, Dave Crocker  wrote:

>
> For completeness:
>
>  Absent further discussion and agreement in the wg, I taking this
> exchange as producing /no/ changes to the spec.
>
> d/
>
>
> On 7/24/2018 7:58 AM, John Levine wrote:
>
>> In article <9da145f4-df6a-4bfa-b3c9-56027b228...@iis.se> you write:
>>
>>> -=-=-=-=-=-
>>> In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp
>>> (SRV), but those “_node names”
>>> are not even mentioned in the RFC. Are they defined elsewhere?
>>>
>>
>> RFC 2782 says that SRV's are named with _proto where proto is is a
>> protocol name.  RFCs 3588 and 6733 say to do _sctp SRV lookups, but
>> don't further define them, and only have 2782 as an informative
>> reference.  No RFC mentions _dccp.
>>
>> It seems to me that 2782 is the right reference for _sctp.  For _dccp
>> we've had arguments about whether 2782 says that a SRV can be named by
>> any protocol so maybe we should put in every protocol in the IANA
>> registry.  That's a lot of dead protocols.  A reasonable compromise
>> would be to start the registry with the names that have some evidence
>> of being used somewhere, so we could drop _dccp
>>
>> In the same table, the draft refers to RFC 7553 for a number of URI _node
>>> names, but the references are quite
>>> indirect. Could references to relevant IANA registries be added?
>>>
>>
>> Since RFC 7553 is the place that says that the enumservice names turn
>> into _node names, I think that's the right reference.
>>
>
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> ___
> 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] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread Dave Crocker


For completeness:

 Absent further discussion and agreement in the wg, I taking this 
exchange as producing /no/ changes to the spec.


d/


On 7/24/2018 7:58 AM, John Levine wrote:

In article <9da145f4-df6a-4bfa-b3c9-56027b228...@iis.se> you write:

-=-=-=-=-=-
In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), 
but those “_node names”
are not even mentioned in the RFC. Are they defined elsewhere?


RFC 2782 says that SRV's are named with _proto where proto is is a
protocol name.  RFCs 3588 and 6733 say to do _sctp SRV lookups, but
don't further define them, and only have 2782 as an informative
reference.  No RFC mentions _dccp.

It seems to me that 2782 is the right reference for _sctp.  For _dccp
we've had arguments about whether 2782 says that a SRV can be named by
any protocol so maybe we should put in every protocol in the IANA
registry.  That's a lot of dead protocols.  A reasonable compromise
would be to start the registry with the names that have some evidence
of being used somewhere, so we could drop _dccp


In the same table, the draft refers to RFC 7553 for a number of URI _node 
names, but the references are quite
indirect. Could references to relevant IANA registries be added?


Since RFC 7553 is the place that says that the enumservice names turn
into _node names, I think that's the right reference.




--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-25 Thread Mats Dufberg
RFC 8145 defines the _ta- node name:

   A Key Tag query consists of a standard DNS query of type NULL and of
   class IN [RFC1035].

   The first component of the query name is the string "_ta-" followed
   by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag
   values.  The zone name corresponding to the trust anchor is appended
   to this first component.

   (RFC 8145, page 8)

_ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf.



Mats

---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/
 


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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-24 Thread Dave Crocker

On 7/23/2018 2:22 PM, Tim Wicinski wrote:

ooks like a typo.  That has been there for a bit.


...

  The table on page 6 includes:

"._protoB._service2"



Given that it's the only one like that, yes, it should be changed.

Just to bikeshed the issue, note that it's not 'wrong' to have the dot 
there, given the nature of this registration activity and therefore the 
context that the examples are going to get used in.


But certainly things need to be consistent and that one isn't.

Thanks for catching it, Bob.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-24 Thread John Levine
In article <9da145f4-df6a-4bfa-b3c9-56027b228...@iis.se> you write:
>-=-=-=-=-=-
>In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), 
>but those “_node names”
>are not even mentioned in the RFC. Are they defined elsewhere?

RFC 2782 says that SRV's are named with _proto where proto is is a
protocol name.  RFCs 3588 and 6733 say to do _sctp SRV lookups, but
don't further define them, and only have 2782 as an informative
reference.  No RFC mentions _dccp.  

It seems to me that 2782 is the right reference for _sctp.  For _dccp
we've had arguments about whether 2782 says that a SRV can be named by
any protocol so maybe we should put in every protocol in the IANA
registry.  That's a lot of dead protocols.  A reasonable compromise
would be to start the registry with the names that have some evidence
of being used somewhere, so we could drop _dccp

>In the same table, the draft refers to RFC 7553 for a number of URI _node 
>names, but the references are quite
>indirect. Could references to relevant IANA registries be added?

Since RFC 7553 is the place that says that the enumservice names turn
into _node names, I think that's the right reference.

R's,
John


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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-24 Thread Mats Dufberg
In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), 
but those “_node names” are not even mentioned in the RFC. Are they defined 
elsewhere?

In the same table, the draft refers to RFC 7553 for a number URI _node names, 
but the references are quite indirect. Could references to relevant IANA 
registries be added?


Mats

---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/


From: DNSOP  on behalf of Bob Harold 

Date: Monday, 23 July 2018 at 22:22
To: IETF DNSOP WG 
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt


On Sat, Jul 21, 2018 at 12:11 PM 
mailto:internet-dra...@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Scoped Data Through "Underscore" Naming of 
Attribute Leaves
Author  : Dave Crocker
Filename: draft-ietf-dnsop-attrleaf-12.txt
Pages   : 13
Date: 2018-07-21

Abstract:
   Formally, any DNS resource record may occur under any domain name.
   However some services have defined an operational convention, which
   applies to DNS leaf nodes that are under a DNS branch having one or
   more reserved node names, each beginning with an _underscore.  The
   underscored naming construct defines a semantic scope for DNS record
   types that are associated with the parent domain, above the
   underscored branch.  This specification explores the nature of this
   DNS usage and defines the "DNS Global Underscore Scoped Entry
   Registry" with IANA.  The purpose of the Underscore registry is to
   avoid collisions resulting from the use of the same underscore-based
   name, for different services.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-12
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-12


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


Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-23 Thread Tim Wicinski
Bob

Looks like a typo.  That has been there for a bit.

Tim


On Mon, Jul 23, 2018 at 4:21 PM, Bob Harold  wrote:

>
> On Sat, Jul 21, 2018 at 12:11 PM  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations WG of the
>> IETF.
>>
>> Title   : DNS Scoped Data Through "Underscore" Naming of
>> Attribute Leaves
>> Author  : Dave Crocker
>> Filename: draft-ietf-dnsop-attrleaf-12.txt
>> Pages   : 13
>> Date: 2018-07-21
>>
>> Abstract:
>>Formally, any DNS resource record may occur under any domain name.
>>However some services have defined an operational convention, which
>>applies to DNS leaf nodes that are under a DNS branch having one or
>>more reserved node names, each beginning with an _underscore.  The
>>underscored naming construct defines a semantic scope for DNS record
>>types that are associated with the parent domain, above the
>>underscored branch.  This specification explores the nature of this
>>DNS usage and defines the "DNS Global Underscore Scoped Entry
>>Registry" with IANA.  The purpose of the Underscore registry is to
>>avoid collisions resulting from the use of the same underscore-based
>>name, for different services.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-12
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-12
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-12
>>
>
>  The table on page 6 includes:
>
> "._protoB._service2"
>
>
> Why the dot at the beginning?  None of the other lines have that.
>
>
> --
>
> Bob Harold
>
>
>
> ___
> 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] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-23 Thread Bob Harold
On Sat, Jul 21, 2018 at 12:11 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
> Title   : DNS Scoped Data Through "Underscore" Naming of
> Attribute Leaves
> Author  : Dave Crocker
> Filename: draft-ietf-dnsop-attrleaf-12.txt
> Pages   : 13
> Date: 2018-07-21
>
> Abstract:
>Formally, any DNS resource record may occur under any domain name.
>However some services have defined an operational convention, which
>applies to DNS leaf nodes that are under a DNS branch having one or
>more reserved node names, each beginning with an _underscore.  The
>underscored naming construct defines a semantic scope for DNS record
>types that are associated with the parent domain, above the
>underscored branch.  This specification explores the nature of this
>DNS usage and defines the "DNS Global Underscore Scoped Entry
>Registry" with IANA.  The purpose of the Underscore registry is to
>avoid collisions resulting from the use of the same underscore-based
>name, for different services.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-12
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-12
>

 The table on page 6 includes:

"._protoB._service2"


Why the dot at the beginning?  None of the other lines have that.


-- 

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


[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

2018-07-21 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Scoped Data Through "Underscore" Naming of 
Attribute Leaves
Author  : Dave Crocker
Filename: draft-ietf-dnsop-attrleaf-12.txt
Pages   : 13
Date: 2018-07-21

Abstract:
   Formally, any DNS resource record may occur under any domain name.
   However some services have defined an operational convention, which
   applies to DNS leaf nodes that are under a DNS branch having one or
   more reserved node names, each beginning with an _underscore.  The
   underscored naming construct defines a semantic scope for DNS record
   types that are associated with the parent domain, above the
   underscored branch.  This specification explores the nature of this
   DNS usage and defines the "DNS Global Underscore Scoped Entry
   Registry" with IANA.  The purpose of the Underscore registry is to
   avoid collisions resulting from the use of the same underscore-based
   name, for different services.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-12
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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