Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

[<[e-mail]>]

Dear Hesham,

Thanks for the review.

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : Hesham Soliman [mailto:[e-mail]] 
>Envoyé : vendredi 21 septembre 2012 09:39
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : IPv6 Ops WG
>Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
>
>A few quick comments on the drat having gone through it quickly.
>
>1. Requirements 1 and 2 are sort of redundant in an IETF document. The
>purpose od RFC 3316 was t specify IETF protocols that should 
>be supported
>by the cellular host. PDP context has nothing to do with IETF protocols
>and functionally speaking it's outside of the IP stack. 
>Therefore, I see
>no reason for specifying this in an RFC. It's not harmful, but 
>since it's
>specified elsewhere, having such redundancy can lead to 
>confusion if 3GPP
>specs change for example. So it's best to remove them.

Med: I see the point but we consider it from another perspective: We tried to answer to the question "What a device should support in order to be IPv6-compliant + be able to be connected to a3GPP network". There is no single document defining an IPv6 profile for cellular hosts/devices. We wanted a single document listed both IETF and 3GPP specification. 

>
>2. Same goes for the PCO. out of scope. It's no different than the IP
>stack "finding" these parameters in a file that come from "somewhere".

Med: Same as above.

>
>3. Req 5, I suggest a MAY instead of a SHOULD.

Med: I just found this req conflicts with REQ#19. I will double check. 

>
>4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively
>requiring these functions for all deployments? It seems like a big
>mandate, who's pushing for this? Just need to see that we have 
>consensus
>on this. I think Req 8 has the right keyword "MAY" and the same should
>apply to 6 and 7 IMO.

Med: These are important features to support if we want IPv6-only connectivity model to fly. 

>
>5. REQ 9 and 10 are also too strong. This is a MAY by the definition of
>keywords. It's an optimisation.

Med: There are various reasons to have PCP as SHOULD: save the battery consumption, reduce keepalive message, Control and retrieve the lifetime of NAT bindings, ease NAT and firewall traversal for application embedding IP address and/or port number(s) in the application payload, allow for successful inbound communications and for the capability to control outgoing connections, control and retrieve the lifetime of NAT bindings (including implicit ones), allow NAT binding recovery, trigger applications to repairs their bindings whenever this is required.

>
>6. REQ 18 repeats 3316, although the reference has changed, so it's
>redundant. 
>
>7. REQ 19 conflicts with REQ 5, MAY Vs SHOULD. If they're both 
>MAY I'm ok
>with that. 

Med: Thanks for catching this.

>
>8. REQ 21 is completely redundant because this behaviour is 
>mentioned in
>RFC 3314, 3316 and 3GPP specs.
>
>9. REQ 27: For 3GPP specs there are defined standards for discovering
>their servers. Why would you list another mechanism not 
>related to 3GPP?

Med: This is an optional feature which would solve an issue of bootstrapping in a non-3GPP network. I have added a note in http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316update-01: 

         [DISCUSSION NOTE: Since this is still an individual submission,
         should we remove this item?]


>The purpose of the draft is to address a specific deployment. 
>General IETF
>specs are available to all implementers and they can decide 
>for themselves
>what they want to implement on top of the base.
>
>10. I disagree with REQ 28. This is an experimental RFC. If 
>someone does
>it that's fine, but no need to mandate it here.

Med: This is for a CPE-like service. We need a solution for the issue discussed in that REQ. RFC4389 is what we have now. If there is any better ref, I can add it.

>
>11. REQ#29: "The cellular device MUST support Prefix Delegation
>      capabilities [RFC3633 <http://tools.ietf.org/html/rfc3633>].
>Particularly, it MUST behave as a
>      Requesting Router."
>
>=> Why? Where did this come from? I disagree with this 
>requirement. It's
>up to each implementation to decide that. At best, you could have a MAY
>but it's completely redundant. And as a consequence, so is REQ 30.
>

Med: REQ#29 and REQ#30 have been merged in -01 (http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316update-01)

>
>12. REQ#31:  The cellular device SHOULD support Customer Side 
>Translator
>      (CLAT) [I-D.ietf-v6ops-464xlat
><http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-req
>s-rfc3316upd
>ate-00#ref-I-D.ietf-v6ops-464xlat>].
>
>=> Why? Why SHOULD? Again, at best a MAY.

Med: This is for the case where there is an IPv4 host connected behind the cellular CPE.

>
>Thanks,
>Hesham
>