Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-4over6-provisioning-04: (with COMMENT)

Hi Ben,
Thanks for the comments. Please see my reply below:

Best Regards,
Cathy

> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: Thursday, August 06, 2015 3:59 AM
> To: The IESG
> Cc: draft-ietf-dime-4over6-provisioning@ietf.org; dime-chairs@ietf.org;
> dime@ietf.org; draft-ietf-dime-4over6-provisioning.shepherd@ietf.org;
> draft-ietf-dime-4over6-provisioning.ad@ietf.org
> Subject: [Dime] Ben Campbell's No Objection on
> draft-ietf-dime-4over6-provisioning-04: (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-dime-4over6-provisioning-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-dime-4over6-provisioning/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for an easy-to-read document. I have a few questions and comments,
> that I hope can be resolve easily:
> 
> -- 3.2:
> Is it possible (or reasonable) for the FQDN to include an internationalized
> domain name? That is, is there a need for a idn or precis dependency? (I'm not
> saying there _is_ such a need; I'm just
> asking.)
I think it is possible for the FQDN to include an IDN. But this document does not define the FQDN encoding. 
It just follows the definition in RFC1035, RFC1123 and RFC2181.
> 
> -- 6.1, 2nd paragraph:
> 
> So you mean MiTM attacks _on_ peers, or _by_ peers? I assume the second,
> since the first can be mitigated with TLS. (I’m not sure I would call this a MiTM
> per se, it’s just an issue that compromised or malicious nodes already in the
> path may do bad things.)
The MiTM attacker may alter the information sent between the peers. So you are right, it should be changed to "by_peers". Thanks.

> 
> -- 6.2:
> Thanks for including this--but I think it needs a bit more.  I assume from these
> sections that some of these AVPs are "security-sensitive" as defined in the
> referenced section of RFC 6733. That section invokes requirements to use
> mutually authenticated TLS or IPSec, and to be sure that messages do not
> traverse any nodes that are not explicitly trusted.
> It would be good to explicitly list which AVPs from this draft qualify as such
> (unless the answer is "all of them"), and to explicitly mention that the
> additional requirements apply to their use.
I think all the AVPs in this draft qualify the requirements defined in RFC 6733.
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime