Hi Erik, Thank you for the review. Please see inline. Cheers, Med >-----Message d'origine----- >De : v6ops-bounces@xxxxxxxx [mailto:v6ops-bounces@xxxxxxxx] De la part de >Erik Kline >Envoyé : jeudi 22 août 2013 13:22 >À : Owen DeLong >Cc : v6ops@xxxxxxxx; IETF Discussion >Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile- >04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile >Devices) to Informational RFC > >REQ 1: > 6434 5.9.1 is already a MUST. This does not need to be repeated. [Med] Because some requirements are stronger in this document than what is documented in RFC6434, we had two way to implement this in the document: (a) Indicate RFC6434 must be supported with the exceptions in the language for some requirements listed in this document. (b) Call out explicitly the requirements from RFC6434 that are mandatory + indicate which requirements are stronger than rfc6434. We decided to go for (b) as it provides a comprehensive list of requirements for 3GPP mobile devices grouped in one single document. IMHO, this is just a matter of presentation. This rationale is explained in the introduction. > 6434 5.8 is already a MUST. Unless you want to make multipart >ICMP a MUST (why?) as well, this too can be removed. > >REQ 6: > re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST > frankly even 5.2 reads like MUST for 3GPP, but it does SHOULD so >this MUST appears stronger. Bizarre, though, I never noticed that "ND >SHOULD" before. [Med] The language is stronger compared to the SHOULD in Section 5.2 of RFC6434. > >REQ 10: > this reads kind weird. In REQ 9 you require 6106 support, but in >REQ 10 you say "if 6106 is not supported." I think you mean something >like "if the network to which the mobile node is attaching does not >support 6016". [Med] Yes, agree. As mentioned in the document, " Some of the features listed in this profile document require to activate dedicated functions at the network side." This will be fixed.