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

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jul 2015 11:49:24 +0100

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.

- 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.

- 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.

- 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:-)

- 2.5, typo: s/Pv4/IPv4/

- 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.

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

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Thu, 9 Jul 2015 06:37:01 +0000

Dear Stephen,

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

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

From: DiME [mailto:[email-masked]] On Behalf Of Stephen Farrell

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

To: [email-masked]

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

Hiya,

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

[email-masked]

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Jul 2015 10:37:44 +0100

Hi Cathty,

Those all look good. One question below though

Cheers,
S.

On 09/07/15 07:37, Zhouqian (Cathy) wrote:
> 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.
> 
> 
> 
> - 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.
> 
> 
> 
> - 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.

Hmm. So you can't allocate a port to someone unless they send a
packet using that as the source port? That seems a bit odd to me.
How would one support a server in such a case?

> - 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
>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 9 Jul 2015 07:08:54 -0400

> Those all look good. One question below though
...
> How would one support a server in such a case?
...
[PTT] This is typical behaviour for a NAT. However, it is also possible 
to set up static allocations, and you probably would for a server.