Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix

[Warren Kumari <[e-mail]>]

[ - Adam, -DNSOP, +Dave Crocker ]

Hi there Alissa,

You are still holding a DISCUSS position on this document -- I *think* that
it (and the companion) are now OK.
Would you mind having a look and seeing if you can clear?
W

On Sun, Nov 4, 2018 at 5:21 AM Warren Kumari <[e-mail]> wrote:

> So, the new version of draft-ietf-dnsop-attrleaf-fix is posted --
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/
> The diff from the previous is here:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-fix-06
>
> I **think** that this addresses the outstanding issues (modulo some
> formatting nits) -- Alissa / Adam, does this satisfy your concern?
>
> W
>
> On Mon, Oct 22, 2018 at 11:34 PM Adam Roach <[e-mail]> wrote:
>
>> On 10/19/18 7:08 AM, Warren Kumari wrote:
>>
>> So, there were a few documents where I was not able to quickly figure out
>> which of the classes it should be placed in.
>>
>>
>> tl;dr: my analysis is that all four of the mentioned documents should be
>> removed from the list. Details below.
>>
>>
>> RFC3861 describes how to use SRV, but it is updated by RFC6121, which
>> largely says "Don't!" -- what do we do here? Update both? Just RFC3861?
>> Juast RFC6121?
>>
>>
>> That's sort of true. 3861 defines rules for _im._x and _pres._x (for
>> arbitrary values of "x"), while 6121 says "don't do this for x = xmpp."
>> For example, RFC 5509 builds on RFC 3861 for SIP, and it's technically
>> still in effect (although the practical case is probably the same as XMPP,
>> no one has produced a revision to 5509 that says as much).
>>
>> All of that notwithstanding, 3861 most definitely does not deal with
>> "Global" underscored node names as -attrleaf- defines that term. It deals
>> only with labels further down the tree. I believe it should be removed from
>> the list.
>>
>>
>> I couldn't figure out RFC3404, and RFC6011.
>> Clue appreciated.
>>
>> RFC3404 -- Dynamic Delegation Discovery System (DDDS) Part Four: The
>> Uniform Resource Identifiers (URI) Resolution Application
>> Perhaps SRV? But it doesn't really seem to be underscore scoped...
>>
>>
>> This one is quite perplexing, and I don't know how it got caught up in
>> Dave's net. The character "_" appears only 12 times in this document, all
>> in variable names in the pseudo-code in its appendix. Neither of the
>> English words "underscore" nor "underline" appear at all.
>>
>> As far as I recall (and a quick skim seems to validate this), the only
>> reservations DDDS makes are under "urn.arpa." and "uri.arpa." -- there
>> aren't any global name reservations, with or without underscores.
>>
>> I think this document was included in error.
>>
>>
>> RFC6121 -- Extensible Messaging and Presence Protocol (XMPP): Instant
>> Messaging and Presence
>> This updates RFC3921 and explicitly recommends against SRV.
>> "Interoperability Note: RFC 3921 specified how to use the _im._xmpp and
>> _pres._xmpp SRV records [IMP-SRV] as a fallback method for discovering
>> whether a remote instant messaging and presence service communicates via
>> XMPP. Because those SRV records have not been widely deployed, this
>> document no longer specifies their use, and new implementations are not
>> encouraged."
>> Should this be in this list?
>>
>>
>> RFC 6121, as you point out, only mentions _{im,pres}.xmpp as an
>> historical note while deprecating its use. I believe it should also be
>> removed.
>>
>>
>>
>> RFC3861 -- Extensible Messaging and Presence Protocol (XMPP): Instant
>> Messaging and Presence
>> See above. It would be SRV, but was updated by RFC6121.
>>
>>
>> [see above]
>>
>>
>>
>> RFC6011 -- Session Initiation Protocol (SIP) User Agent Configuration
>> I got confused here -- I cannot really see the underscore names here as
>> anything other than a target name.
>>
>>
>> 6011 shouldn't be updated by this document. The only underscored node
>> names in that document are in non-normative examples, and they're actually
>> incidental to the purpose of the example. Presumably, they're included to
>> demonstrate that querying for NAPTR records can return both UA Config
>> records **and** other, unrelated records, and that implementations need
>> to ignore the unrelated records.
>>
>>
>> Thanks for doing the heavy lifting on this. I think it has dramatically
>> improved the document to figure out why each updated RFC is included, since
>> it flushed out several that should not be.
>>
>> /a
>>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf