Subject: Re: [xmpp] IETF 86 Draft Agenda

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Mar 2013 11:12:42 -0700

On 2/27/13 11:30 AM, Ben Campbell wrote:
> Hi Everyone,
> 
> We have a 1 hour session for XMPP scheduled at IETF 86 (Orlando).
> The draft agenda is available at the following link:
> 
> http://www.ietf.org/proceedings/86/agenda/agenda-86-xmpp
> 
> Please send any agenda concerns or other feedback to the list as
> soon as possible.

Seems fine!

Matt and I have put together some slides for the DNA topic:

https://stpeter.im/files/ietf86-xmpp-dna.pdf

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 04 Mar 2013 22:46:14 +0100

> https://stpeter.im/files/ietf86-xmpp-dna.pdf

Some feedback on those. No changes to the slides required, tuning the 
audio track should be sufficient ;-)

slide 2, bullet 1:
 > for the ﬁrst domain pair

I don't think the distinction between "first domain pair" and additional 
domain pairs (as seen in the flow chart, section #3 in dna-01) is necessary.
However, that is up to the receiving server. If it offers the EXTERNAL 
sasl mechanism, it is preferred. If it doesn't, it should smoothly 
degrade to <db:result/> exchanges (checked using DNA rules).
No problem here.

slide 3, bullet 2:
 > (checked using DNA rules)

No, the point is that the receiving server can use ANY checks it likes. 
For the sending server, it does not make any difference.
(that assumes the sending server already knows the receiving server is
  authorized to handle stanzas for that domain. Which is done by DNA)

slide 4, bullet 3:
 > In DNA, not a prooftype

Much as I'd like to deprecate the <db:verify/> mechanism I think it can 
(and should be; 99% deployment) described in terms of a DNA proof. But 
that belongs into xep-0220 and is therefore not an xmppwg concern ;-)

slide 4, bullet 4:
 > As noted, used only to assert / “suppose” subsequent domain pairs

I think it is worth pointing out that this only reuses the <db:result/>. 
Essentially, it removes the not-an-authentication-mechanism dialing-back 
part from "server dialback" and only leaves the authorization protocol part.

LGTM otherwise, thanks!