Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

[Sheng Jiang <[e-mail]>]

>> Agree. The network providers should know they cannot get more addresses
>because they use their block for semantic, which lead to lower address utility
>rate.
>>
>> Will make this clear in the new section "potential pitfalls".
>
>Sheng -
>
>  It would be very helpful to put that clarifying point into the draft
>  text,  i.e. ("cannot get more addresses because they use their block
>  for semantic"). Note that it would just as helpful to include the
>  converse (i.e. "ISPs should be able to get sufficiently sized address
>  blocks to allow semantic prefix use"); it really doesn't matter which
>  phrase you include as long as the intent is clear to everyone.  Your
>  draft is very likely create less controversy if it states that one
>  cannot get more addresses automatically because of semantic use, but
>  ultimately the most important point is clarity of the intent either way.
>
>  While the IETF does not set RIR policy, IETF recommendations are often
>  raised in the RIR policy development process. This means that an RFC
>  (even informational, even individual contribution) may be raised as
>  justification for why RIR policy should be changed.  Clearly, a working
>  group output RFC and/or BCP carries more weight in the discussions that
>  follow, but it is not inconceivable that publication of an esoteric IPv6
>  use case (which requires larger ISP allocations) would kickoff discussions
>  for changes to IPv6 ISP allocation policy.  The tradeoffs in appropriate
>  management of the vast (but still fixed) IPv6 free pool will obviously
>  need to be considered, as will the actual community demand for that type
>  of technological solution, but recognize that the RIRs job is facilitate,
>  not hinder, the distribution of IP addresses and that means trying to
>  accommodate whatever technical work comes out of the IETF.

Hi, John,

Thanks for your message. Yes, I will add lower address utility rate as one of the major pitfalls. However, I don't want to make an absolute statement of "cannot". As a neutral analysis, it is better to just make observation, such as "there is risk that they may not". We do not want to influence the RIR policy either way, which would be quite controversial. It is better we do not touch this.

Cheers,

Sheng

>FYI,
>/John
>
>Disclaimer:  My views alone.  I am unaware of any formal consideration
>             by ARIN (or the IETF, for that matter) of how IETF RFC's
>             should interact with the RIR policy process, but the above
>             ramblings reflect my best understanding of relationship.