Subject: [appsdir] Fwd: Peter Saint-Andre's No Objection on draft-ietf-mile-rfc6046-bis-07: (with COMMENT)

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jan 2012 17:48:17 -0700

And a second one...

-------- Original Message --------
Subject: Peter Saint-Andre's No Objection on
draft-ietf-mile-rfc6046-bis-07: (with COMMENT)
Date: Wed, 18 Jan 2012 12:07:00 -0800
From: Peter Saint-Andre <[email-masked]>
To: The IESG <[email-masked]>
CC: [email-masked], [email-masked]

Peter Saint-Andre has entered the following ballot position for
draft-ietf-mile-rfc6046-bis-07: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

First, thank you for addressing the comments that Julian Reschke
provided on behalf of the Apps Directorate.

Section 3 states:

   RID systems MAY be configurable to listen on
   ports other than the well-known port; this configuration is out of
   band and out of scope for this specification.

and:

   When performing RID callback, a responding system MUST connect to the
   host at the network-layer address from which the original request was
   sent; there is no mechanism in RID for redirected callback.  This
   callback SHOULD use TCP port 4590 unless configured out of band to
   use a different port.

What does it mean to configure a RID system out of band? As far as I can
see there is no *in-band* configuration method (i.e., a RID system
cannot be configured via RID messages), so the use of "out of band" here
is confusing. I suggest removing this terminology in both instances.

The ABNF reference is old; please change [RFC2234] to [RFC5234].

Section 3 states:

   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
   authentication for confidentiality, identification, and
   authentication, as in [RFC2818], when transporting RID messages over
   HTTPS.

The phrase "as in [RFC2818]" makes it sound as if the rules specified in
RFC 2818 are the kind of rules that might be used, not that those rules
must be followed. If the intent is that the identity-checking rules in
RFC 2818 always apply to RID systems, I suggest changing the text to:

   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
   authentication for confidentiality, identification, and
   authentication when transporting RID messages over HTTPS.  RID
   systems MUST follow the rules specified in [RFC2818] regarding
   verification of endpoint identities.