Hi Simon,

Ok to move rfc3316bis to the normative references. 

I implemented all the changes we agreed. FWIW, I will send you a message when the new revision is available online.

Many thanks for your review. Much appreciated.

Cheers,
Med

>-----Message d'origine-----
>De : Simon Josefsson [mailto:simon@josefsson.org]
>Envoyé : lundi 2 septembre 2013 16:31
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : secdir@ietf.org; iesg@ietf.org; draft-ietf-v6ops-mobile-device-
>profile.all@tools.ietf.org
>Objet : Re: secdir review of draft-ietf-v6ops-mobile-device-profile-04
>
>You wrote:
>
>> >A notable point is that there is no discussion or references to IPSec
>>
>> [Med] IPsec is not explicitly mentioned in this document as it is
>> discussed in these two references cited in the "Security
>> Considerations" section: rfc3316bis and rfc6092. Is there any
>> particular change you want us make in the "Security Considerations"
>> section? Thanks.
>
>No -- that was a general observation.  However both rfc3316bis and
>rfc6092 are informative references in your document, so what you say
>above combined with...
>
>> >in the document, nor any of the IPv6 "bugs" (e.g., RFC 5722 and RFC
>> >6946).  There may be other document that could be referenced that
>> >would lead to improved security, but it is hard to list them all.
>>
>> [Med] We didn't included explicit references to RFC5722 and RFC6980
>> as those are already cited in rfc3316bis. "Security Considerations"
>> refers explicitly to rfc3316bis. Is there any particular change you
>> want us to make in "Security Considerations" section? Thanks.
>
>...what you say here makes it sounds as if rfc3316bis should be a
>normative reference to me.  It seems like reading rfc3316bis is
>essential to get a good understanding of this document.
>
>> >This document seems related to draft-ietf-v6ops-rfc3316bis which
>> >describe another IPv6 profile for 3GPP hosts.  The utility of having
>> >two different IPv6 profiles for 3GPP hosts could be discussed, but it
>> >is only a security issue in the marginal sense that complexity often
>> >leads to poor security.
>> >
>> >The security considerations of this document is only pointers to
>> >the security considerations of RFC3316bis, RFC6459, and RFC6092 which
>> >feels underwhelming to me -- especially since the RFC3316bis security
>> >consideration is for the particular profile that RFC3316bis defines.
>> >The security considerations of RFC3316bis wouldn't automatically
>> >apply to the profile defined by
>> >draft-ietf-v6ops-mobile-device-profile since the profiles are
>> >different.
>>
>> [Med] The relationship between the two documents is explained in the
>> introduction; in particular:
>>
>>    This document defines a different profile than the one for general
>>    connection to IPv6 mobile networks defined in
>>    [I-D.ietf-v6ops-rfc3316bis]; in particular:
>>
>>    o  It lists an extended list of required features while
>>       [I-D.ietf-v6ops-rfc3316bis] identifies issues and explains how
>> to implement basic IPv6 features in a cellular context.
>>
>>    o  It identifies also features to ensure IPv4 service delivery over
>>       an IPv6-only transport.
>>
>> Because of this difference, this document points to the security
>> considerations of rfc3316bis security section and to RFC6092 because
>> Cellular Devices with LAN capabilities are within the scope of this
>> document.
>
>OK.
>
>> >Other notes:
>> >
>> >* The document uses RFC 2119 language "for precision", although I
>> >don't
>> >  understand what it means for an Informational document to contain
>> >  MUST languages.
>>
>> [Med] This use is not specific to this document; see for example:
>> http://tools.ietf.org/html/rfc6092#section-1.2. A note was added to
>> the document to explain this usage.
>
>OK.
>
>> >* The document really really should reference RFC 2460.
>>
>> [Med] Done.
>
>Thanks.  Having a normative reference to 2460 also takes care of my
>concern about not referring to RFC 5722 and RFC 6946.
>
>> [Med] I made this change:
>>
>> OLD:
>>    The security considerations identified in
>> [I-D.ietf-v6ops-rfc3316bis] and [RFC6459] are to be taken into
>> account.
>>
>>    REQ#34:  If the cellular device provides LAN features, it SHOULD be
>>           compliant with the security requirements specified in
>>           [RFC6092].
>>
>> NEW:
>>    The security considerations identified in
>> [I-D.ietf-v6ops-rfc3316bis] and [RFC6459] are to be taken into
>> account.
>>
>>    Security-related considerations that apply when the cellular device
>>    provides LAN features are specified in [RFC6092].
>>
>> RFC6092 is already called out in the core part of the document.
>
>Thanks, this seems clearer to me.
>
>> >* I found REQ#32 a bit too generalized.  I believe it is common for
>> >  applications to be aware of whether connections are over IPv4 or
>> > IPv6 and behave differently.
>> >   >REQ#32:  Applications MUST be independent of the underlying IP
>> >   >       address family. This means applications must be IP version
>> >   >       agnostic.
>> >
>>
>> [Med] I agree this is a too generalized requirements. We have it on
>> purpose to encourage applications devs to avoid making assumptions on
>> the underlying available connectivity. FWIW, our teams tested devices
>> that support IPv6 connectivity... but that embed applications which
>> are broken when IPv6 connectivity is enabled (e.g., ip address
>> literals). An education effort is still needed to avoid this kind of
>> brokenness.
>
>I understand and completely agree!
>
>/Simon