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)

Barry Leiba | 9 Jun 13:04 2015
Picon

Barry Leiba's Yes on draft-ietf-xmpp-6122bis-23: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-xmpp-6122bis-23: Yes

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 would make the RFC 6365 reference normative.

The ABNF definition for localpart would benefit from citing
[draft-ietf-precis-saslprepbis] by "UsernameCaseMapped profile". 
Similarly for "OpaqueString profile" in the definition of "resourcepart".
 (And, by the way, I wouldn't put quotation marks around the profile
names.)

The first paragraph of Section 3.2 defines a particular parsing order,
which will affect a JID such as in example 15, way down below.  I think
it's worth explicitly saying that here, to reduce the likelihood that
such JIDs might be mis-parsed.  You do mention it in the note explaining
example 15, but it'd be useful to highlight it here.
(Continue reading)

Alissa Cooper | 8 Jun 15:38 2015
Picon

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

Alissa Cooper 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:
----------------------------------------------------------------------

= Section 6.1 =
"Because this document obsoletes RFC 6122,
   which registered the "Nodeprep" and "Resourceprep" profiles, IANA is
   requested at the least to mark those profiles as not current
   (preferably with a pointer to this document)."

"At the least" implies that IANA may take some further action at its own
discretion, which doesn't seem right. I would suggest deleting that
phrase.
The IESG | 21 May 01:36 2015
Picon

Last Call: <draft-ietf-xmpp-6122bis-22.txt> (Extensible Messaging and Presence Protocol (XMPP): Address Format) to Proposed Standard


The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'Extensible Messaging and Presence Protocol (XMPP): Address Format'
  <draft-ietf-xmpp-6122bis-22.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-06-03. 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.

Abstract

   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.

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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ballot/

No IPR declarations have been submitted directly on this I-D.

Gmane