Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

[Pete Vickers <[e-mail]>]

Hi,

<lurk mode off>

I'm very please with the way this draft is starting to look, just a follow up on Victor's note though: Given that the 'DNS info' preference order is set for multiple values received over cellular interface, I believe that in the interests of consistent behaviour the same preference order should also be mandated for wifi interface acquired values. I think this effectively adds REQ 19.5 as SLACC, which is also fine by me. 


regards,

Pete Vickers








On 14. nov. 2012, at 21.00, [e-mail] wrote:


> 
> 
> Message: 3
> Date: Tue, 13 Nov 2012 22:12:22 -0500
> From: Victor Kuarsingh <[e-mail]>
> To: <[e-mail]>,	<[e-mail]>
> Cc: [e-mail]
> Subject: Re: [v6ops] new draft:
> 	draft-binet-v6ops-cellular-host-requirements
> Message-ID: <[e-mail]>
> Content-Type: text/plain;	charset="US-ASCII"
> 
> V6ops/Draft Authors,
> 
> Here are some comments on the updated draft (and it's relation to
> draft-korhonen-v6ops-rfc3316bis-00).  I hope there is not too much overlap
> with other comments, I have not had time to review those as of yet.
> 
> I would agree with the WG discussion that this draft
> (v6ops-cellular-host-requirements) is quite different then
> draft-korhonen-v6ops-rfc3316bis-00 but there is some overlap (does not
> bother me as long as they are consistent where they overlap or it
> references the 3316bis document and removes the local document text)
> 
> ON this draft:
> 
> 
> SECTION 2.1 - Wi-Fi
> IN section 2.1 (Wi-Fi) there is a very short set of requirements stated
> for the Wi-Fi interface.  Given that this document is focused on the 3GPP
> interface and operation, perhaps you can just point to RFC 6434 (IPv6 Node
> Requirements).  
> 
> I note that since you don't mention SLACC in section 2.1, but do mention
> DHCPv6 (I would think that SLACC is likely a good idea to specify)
> 
> Perhaps to make it easy, put RFC 6434 in REQ#19?
> 
> 
> OVERALL
> 
> The draft seems to have a definite parallel target for 464XLAT operation.
> But most of the those requirements are SHOULDs in this document.
> 
> I would think that some operators and handsets will want 464XLAT and some
> may not care (I am of the former myself - I want 464XLAT).
> 
> That said, if a cell host needs to operate on a 464XLAT network, perhaps
> we need MUSTs in there?
> 
> Would it make sense to spit off the requirements for 464XLAT and make them
> MUSTs within that section?  Since they would be in different section, we
> can say "If the cellular host is intended to support 464XLAT operation,
> then the following section applies". (or something to that effect).
> 
> Regards,
> 
> Victor Kuarsingh
> 
>