Hi,

On Aug 11, 2011, at 4:27 AM, Thomson, Martin wrote:

> On 2011-08-09 at 18:28:05, jouni korhonen wrote:
>>> It's easy to infer from reading further that "layer-2" implies "pre-
>> IP", but that view is at odds with the view that other nodes 
>> necessarily have: signaling is distinctly layer-7 to those that 
>> operate upon it.  Is this accurate?
>> 
>> Right.. maybe we should also say that PDP context/EPS bearer setup 
>> procedures equals setting up the layer-2 link and the address 
>> configuration can be part of that signaling?
> 
> I notice that you use the term "bearer" fairly frequently to refer to both 
> PDP context/EPS bearer.  When you say "layer-2 signaling" you could be more 
> specific and say "bearer setup".

Right.. how about:

   specifications, but is not used in wide scale.  The mobile host must
   always support address configuration as part of the bearer setup signaling,
   since DHCPv4 is optional for both mobile hosts and networks.

> 
> 
>>>  the 'delegated prefix' [I-D.ietf-dhc-pd-exclude].
>> 
>> In its 3rd WGLC as we speak.
> 
> Great.  MISREF wont keep this in the editors queue long then.
> 
>> The pd-exclude is referenced from 3GPP. How about:
>> 
>>   is not part of the 'delegated prefix'.  IETF defined solution to
>>   exclude a specific prefix from the 'delegated prefix' is used to
>>   enable this [I-D.ietf-dhc-pd-exclude].
> 
> Or just:
>  An option to exclude a prefix from delegation [I-D....pd-exclude] 
>  prevents this problem.

Ok. Sounds much better.

>>> There are more than the usual quantity of acronyms in this document.
>> Welcome to 3GPP ;)
> 
> Oh, it's not my first time, trust me.  Incidentally, I have to note that 
> you've done an excellent job with the acronyms on the whole.  I didn't 
> encounter any that I didn't know, and only a few that weren't expanded.
> 
>> Ok. I'll try fitting clouds there.
> 
> BTW, nice clouds, and some of the nicest ASCII art that I've seen.
> 
>> Do you have a suggestion for better wording? The statement is here 
>> because it is possible and rather easy to deploy a network that allow 
>> other types of handovers. However, in that case the outcome is 
>> unpredictable, especially when the network has equipment from multiple 
>> vendors.. and those cases and recovery procedures are not even 
>> documented.
> 
> I understand that it _is_ unfortunate.  As you say, it has other more 
> concrete consequences.  In some cases, simply removing the "Unfortunately," 
> would work.  Maybe something like:
> 
> OLD:
>   Unfortunately, it is not mandatory to implement/deploy 3GPP standards
>   based solution to selectively prohibit IPv6 roaming without also
>   prohibiting other packet services (such as IPv4 roaming).  However,
>   there are few possibilities how this can be done in real deployments.
>   The examples given below are either optional and/or vendor specific
>   features to the 3GPP EPC:
> NEW:
> 3GPP does not specify a mechanism whereby IPv6 roaming is prohibited without 
> also disabling IPv4 access and other packet services.  The following options 
> for disabling IPv6 access for roaming subscribers could be available in some 
> network deployments:

Thanks. I'll use this.

> Don't feel beholden to me on this one though.  Use your discretion.  The 
> first sentence didn't parse particularly well, but I'm not sure whether my 
> suggestion retains the whole of your original intent.
> 
>> - Jouni
> 
> --Martin

- JOuni


> 
> 

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to