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

[Hesham Soliman <[e-mail]>]

one more comment, I believe RFC 5555 is mentioned in LTE specs. It should
be listed as a MAY IMO.

Hesham

-----Original Message-----
From: Hesham Soliman <[e-mail]>
Date: Friday, 21 September 2012 5:38 PM
To: <[e-mail]>
Cc: IPv6 Ops WG <[e-mail]>
Subject: 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.
>
>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".
>
>3. Req 5, I suggest a MAY instead of a SHOULD.
>
>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.
>
>5. REQ 9 and 10 are also too strong. This is a MAY by the definition of
>keywords. It's an optimisation.
>
>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. 
>
>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?
>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.
>
>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.
>
>
>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-reqs-rfc3316up
>d
>ate-00#ref-I-D.ietf-v6ops-464xlat>].
>
>=> Why? Why SHOULD? Again, at best a MAY.
>
>Thanks,
>Hesham
>
>
>
>
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops