Re: [Dime] AD review of draft-ietf-dime-4over6-provisioning-03

Dear Stephen,

Thank you for your comments, my reply is in line with [CZ]..

-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Stephen Farrell

Sent: Monday, July 06, 2015 6:49 PM

To: dime@ietf.org

Subject: [Dime] AD review of draft-ietf-dime-4over6-provisioning-03

Hiya,

I've done my AD review of draft-ietf-dime-4over6-provisioning-03

Seems to me like all's well. I'll start IETF LC shortly. My few nitty comments are below, please treat then as IETF LC comments.

Thanks,

S.

- intro, 3rd last para: You use both MAP-E and MAP (without a -E) here. Are they the same or is that an implicit subtlty that'd be better explicit? I'd say either use MAP-E in both cases, or explain in general what's meant when you use each.

[CZ]: It should be MAP-E in both cases.

- intro; The last para is very unclear. What does "doesn't specify <x> and that the AVPs...." mean? I'd say split into two sentences.

[CZ]: We will split it as " This document doesn't specify any new commands or Application-Ids. The AVPs specified could be used for any Diameter application suitable for provisioning."

- section 2, 2nd para: Why "allowed to use"? That's wrong anyway, a customer could do other things as well as what one operator provisions for that customer.  S/is allowed/wants/ would be fine.

[CZ]: We will change "allowed" to "wants".

- 2.2 and 2.3: Are we only talking source ports for outgoing traffic here, or is this the list of all ports on which this customer can receive inbound traffic? Would it help to say, since the latter can be bigger than the former? I assume we mean the latter anyway. (This may be a dumb question - sorry if my ignorance of LW4over6 and MAP-E is showing there:-)

[CZ]: We are talking about the source ports here. As defined in LW4over6, when the CE receives an IPv4 packet from the user, it performs a NAPT44 function on the source address and port by using the public IPv4 address and a port number from the allocated port-set.

- 2.5, typo: s/Pv4/IPv4/

[CZ]We will fix it in next version.

- 3.1, I'm surprised there wasn't already an AVP for that. If there is one, or a similar one, it might be good to say and give a bit of a hint when to use which.
[CZ]: There is already an IP-Address-Range AVP defined in [rfc5777], however, there is no definition of the real IP prefix length AVP when it is in a grouped AVP. As also noted in this document, "the IP-Prefix-Length AVP is only relevant when associated with an IP-Address AVP in a Grouped AVP."

- 8.1: the softwire I-D references are outdated. Does everything still work ok with the latest draft versions?

[CZ]: We will update the references in the next version and this dime-provisioning document is consistent with the latest versions.

Best Regards,

Cathy

_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime