MIME-Version: 1.0
In-Reply-To: <30cc33d7-ae70-4192-4f67-377cc9c3b972@dcrocker.net>
References: <20180724145845.1FB912002CE945@ary.qy>
 <30cc33d7-ae70-4192-4f67-377cc9c3b972@dcrocker.net>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Wed, 25 Jul 2018 09:25:57 -0400
Message-ID: <CADyWQ+G-oJuJvzJ2jRGmFWmCWh5GN6WXzF6g1CU_uHD=xMh4mQ@mail.gmail.com>
To: Dave Crocker <dcrocker@bbiw.net>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a05e180571d2d133"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GI3oFrGDeuJMUF8qUwEhcFDbjFM>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
Precedence: list

--000000000000a05e180571d2d133
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

/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 <dhc@dcrocker.net> 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-56027B228050@iis.se> you write:
>>
>>> -=3D-=3D-=3D-=3D-=3D-
>>> In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp
>>> (SRV), but those =E2=80=9C_node names=E2=80=9D
>>> 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 _nod=
e
>>> 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
>

--000000000000a05e180571d2d133
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div>/no/ changes to the spec, except to correct the t=
ypo Bob Harold spotted. =C2=A0 Correct?</div><div><br></div><div><br></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jul=
 25, 2018 at 9:23 AM, Dave Crocker <span dir=3D"ltr">&lt;<a href=3D"mailto:=
dhc@dcrocker.net" target=3D"_blank">dhc@dcrocker.net</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><br>
For completeness:<br>
<br>
=C2=A0 =C2=A0 =C2=A0Absent further discussion and agreement in the wg, I ta=
king this exchange as producing /no/ changes to the spec.<span class=3D"HOE=
nZb"><font color=3D"#888888"><br>
<br>
d/</font></span><span class=3D"im HOEnZb"><br>
<br>
<br>
On 7/24/2018 7:58 AM, John Levine wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In article &lt;<a href=3D"mailto:9DA145F4-DF6A-4BFA-B3C9-56027B228050@iis.s=
e" target=3D"_blank">9DA145F4-DF6A-4BFA-B3C9-56027<wbr>B228050@iis.se</a>&g=
t; you write:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
-=3D-=3D-=3D-=3D-=3D-<br>
In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV=
), but those =E2=80=9C_node names=E2=80=9D<br>
are not even mentioned in the RFC. Are they defined elsewhere?<br>
</blockquote>
<br>
RFC 2782 says that SRV&#39;s are named with _proto where proto is is a<br>
protocol name.=C2=A0 RFCs 3588 and 6733 say to do _sctp SRV lookups, but<br=
>
don&#39;t further define them, and only have 2782 as an informative<br>
reference.=C2=A0 No RFC mentions _dccp.<br>
<br>
It seems to me that 2782 is the right reference for _sctp.=C2=A0 For _dccp<=
br>
we&#39;ve had arguments about whether 2782 says that a SRV can be named by<=
br>
any protocol so maybe we should put in every protocol in the IANA<br>
registry.=C2=A0 That&#39;s a lot of dead protocols.=C2=A0 A reasonable comp=
romise<br>
would be to start the registry with the names that have some evidence<br>
of being used somewhere, so we could drop _dccp<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In the same table, the draft refers to RFC 7553 for a number of URI _node n=
ames, but the references are quite<br>
indirect. Could references to relevant IANA registries be added?<br>
</blockquote>
<br>
Since RFC 7553 is the place that says that the enumservice names turn<br>
into _node names, I think that&#39;s the right reference.<br>
</blockquote>
<br>
<br>
<br></span><span class=3D"im HOEnZb">
-- <br>
Dave Crocker<br>
Brandenburg InternetWorking<br>
<a href=3D"http://bbiw.net" rel=3D"noreferrer" target=3D"_blank">bbiw.net</=
a><br>
<br></span><div class=3D"HOEnZb"><div class=3D"h5">
______________________________<wbr>_________________<br>
DNSOP mailing list<br>
<a href=3D"mailto:DNSOP@ietf.org" target=3D"_blank">DNSOP@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dnsop" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/l<wbr>istinfo/dnsop</a><br>
</div></div></blockquote></div><br></div>

--000000000000a05e180571d2d133--