Kathleen Moriarty | 4 Aug 21:42 2015
Picon

Kathleen Moriarty's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)

Kathleen Moriarty has entered the following ballot position for
draft-ietf-xmpp-posh-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Nice work on this draft!  I do have a few comments that I'd like to chat
about.

In the examples, could you switch them to have sha-256 as the low mark
instead of sha-1?  sha-1 is only a problem if you need collision
resistance, but since it's just used in examples, it might be easier to
just get rid of it.

In the first paragraph of the Security Considerations section, could you
add a reference to RFC7525 as well?  Otherwise, it looks great.  It
should fit in nicely after the RFC2818 reference. Thanks.
Barry Leiba | 29 Jul 11:46 2015
Picon

Barry Leiba's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-xmpp-dna-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Apart from the ".well-known" issue brought up in my comments to
xmpp-posh, I have only one, tiny comment here:

-- Section 1 --

   If such delegation is not done in
   a secure manner, then the domain name association cannot be verified.

Really small point: many people find these sorts of negative-negative
constructions to be confusing, so I suggest this:

NEW
   The domain name association can only be verified when the delegation
(Continue reading)

Barry Leiba | 29 Jul 11:04 2015
Picon

Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-xmpp-posh-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

No objection, in that I'm not going to block on these points, but I do
ask for some discussion, please; see below.

General: You're inconsistent in your use of "URI" and "URL", using the
former in Sections 3 and 8, the latter in Sections 1, 3.2, and 10 -- and,
of course, calling the member "url", rather than "uri".  I'd prefer that
you use "URI", but you should, in any case, be consistent.

-- Section 3 --

   When POSH is used, the first two aspects remain the same: the POSH
   server proves it identity by presenting a PKIX certificate [RFC5280]

(Continue reading)

Ben Campbell | 24 Jun 22:41 2015

AD Evaluation of draft-ietf-xmpp-posh-04

Hi,

This is my AD Evaluation of draft-ietf-xmpp-posh-04. There's nothing 
here to block last call.

Thanks!

Ben.

--------

-- section 3, first paragraph after first numbered list: " ... server 
proves it identity ..."

s/it/its

-- 8, last sentence

With this one sentence, you've made the entire introduction serve as a 
shaggy dog story, without detracting from its main purpose. Bravo. Also, 
groan :-)

-- References:

IDNits turns up several outdated references that probably need attention 
before final publication.
The IESG | 24 Jun 22:32 2015
Picon

Last Call: <draft-ietf-xmpp-dna-10.txt> (Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)) to Proposed Standard


The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'Domain Name Associations (DNA) in the Extensible Messaging and
   Presence Protocol (XMPP)'
  <draft-ietf-xmpp-dna-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2015-07-08. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Please note that this draft has a normative reference to the XMPP Standards Foundation XEP 0220.

Abstract

   This document improves the security of the Extensible Messaging and
   Presence Protocol (XMPP) in two ways.  First, it specifies how to
   establish a strong association between a domain name and an XML
   stream, using the concept of "prooftypes".  Second, it describes how
   to securely delegate a service domain name (e.g., example.com) to a
   target server host name (e.g., hosting.example.net), which is
   especially important in multi-tenanted environments where the same
   target server hosts a large number of domains.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

IESG discussion can be tracked via
(Continue reading)

Ben Campbell | 24 Jun 22:16 2015

AD Evaluation of draft-ietf-xmpp-dna-10

Hi,

Here is my AD Evaluation of draft-ietf-xmpp-dna-10. I have a few minor 
comments, but nothing that needs to delay the last call.

Thanks!

Ben.
-------

-- Section 4.1:

Does the "(Section 4.3: No Mutual PKIX authentication)" belong where it 
is, or before the first dialback assertion?

-- 4.3, step 6:

Do I understand correctly that this step involves A sending a valid and 
trusted server cert, when it was previously unable to send a valid and 
trusted client cert? Is that a reasonable assumption? Whether yes or no, 
does it deserve a mention in the text? (It's likely I am missing 
something that should be obvious.)

-- step 7:

The reference to xep-0344 is informative. Should it be normative? If 
not, then perhaps a stronger mention of skipping subsequent steps should 
be included here? (it’s only mentioned in terms of the reference.)

-- 4.4.1, steps 3 and later:
(Continue reading)

The IESG | 15 Jun 21:17 2015
Picon

Protocol Action: 'Extensible Messaging and Presence Protocol (XMPP): Address Format' to Proposed Standard (draft-ietf-xmpp-6122bis-24.txt)

The IESG has approved the following document:
- 'Extensible Messaging and Presence Protocol (XMPP): Address Format'
  (draft-ietf-xmpp-6122bis-24.txt) as Proposed Standard

This document is the product of the Extensible Messaging and Presence
Protocol Working Group.

The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

Technical Summary

This document defines the address format for the Extensible Messaging
and Presence Protocol (XMPP), including support for code points
outside the ASCII range.  This document obsoletes RFC 6122 to move 
from using stringprep to using precis profiles.

Working Group Summary

This document received review from a small but active number of
individuals from the Working Group and the XMPP Community.  There is
consensus to publish this document.

The XMPP Community did raise the concern that some addresses which are
valid using RFC 6122 are no longer valid using this document.  However,
the consensus of the XMPP Community and the Working Group is that: this
document adequately describes the concerns and potential ways to
resolve such issues; and that such JIDs are exceedingly rare, if they
(Continue reading)

Ben Campbell | 11 Jun 22:06 2015

Approved: draft-ietf-xmpp-6122bis-24

Hi,

draft-ietf-xmpp-6122bis-24 is approved. There are no RFC editor notes.

Thanks!

Ben.
Benoit Claise | 11 Jun 10:42 2015
Picon

Benoit Claise's No Objection on draft-ietf-xmpp-6122bis-23: (with COMMENT)

Benoit Claise has entered the following ballot position for
draft-ietf-xmpp-6122bis-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this operation-related sentence, based on Dan Romascanu's
review:
   Because it is
   possible that previously-valid JIDs might no longer be valid (or
   previously-invalid JIDs might now be valid), operators of XMPP
   services are advised to perform careful testing before migrating
   accounts and other data (see Section 6.1 of
   [I-D.ietf-precis-saslprepbis] for guidance).
Brian Haberman | 10 Jun 21:55 2015
Picon

Brian Haberman's No Objection on draft-ietf-xmpp-6122bis-23: (with COMMENT)

Brian Haberman has entered the following ballot position for
draft-ietf-xmpp-6122bis-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have cleared my DISCUSS based on the changes proposed by PSA.  Thanks
for the quick turnaround.
Brian Haberman | 10 Jun 16:28 2015
Picon

Brian Haberman's Discuss on draft-ietf-xmpp-6122bis-23: (with DISCUSS)

Brian Haberman has entered the following ballot position for
draft-ietf-xmpp-6122bis-23: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be a relatively straightforward DISCUSS and may not result in
any changes to the document...

I see this definition in the draft:
domainpart   = IP-literal / IPv4address / ifqdn
                     ;
                     ; the "IPv4address" and "IP-literal" rules are
                     ; defined in RFC 3986, and the first-match-wins
                     ; (a.k.a. "greedy") algorithm described therein
                     ; applies to the matching process
                     ;
                     ; note well that reuse of the IP-literal rule from
                     ; RFC 3986 implies that IPv6 addresses are enclosed
(Continue reading)


Gmane