Re: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt

[Tom Taylor <[e-mail]>]

OK, I've used Delegated-IPv6-Prefix (RFC 4818) in version -05 where the 
semantics seemed to fit, and otherwise defined Grouped AVPs based on RFC 
5777 IP-Address. Submitted as draft-zhou-dime-4over6-provisioning-05. 
Thanks for your comments.

Tom

On 17/09/2014 10:11 AM, [e-mail] wrote:
> "I can't find Framed-IPv6-Prefix AVP in the IANA registry"
>
> It is because it is one of the reuse of RADIUS attributes and it istom.taylor.stds@gmail.
> therefore part of AVP codes reserved for RADIUS attributes. You can
> look into the table given in
> http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-types-2
>
>
You can also refer to RFC 7155 when the AVP is defined.
>
> If you are considering reusing the Framed-IPv6-Prefix AVP, we may
> also consider reusing the IP-Address AVP (Address type) defined in
> RFC 5777 to convey either an IPv4 or an IPv6.
>
> Again, this is only a proposal and others might have another opinion.
> I just try to move forward this draft in the best and easiest
> direction.
>
> Regards,
>
> Lionel
>
>
> -----Message d'origine----- De : Tom Taylor
> [mailto:[e-mail]] Envoyé : mercredi 17 septembre
> 2014 15:46 À : MORAND Lionel IMT/OLN; [e-mail] Objet : Re:
> [Dime] Fwd: New Version Notification for
> draft-zhou-dime-4over6-provisioning-04.txt
>
> Thank you for your comments. I think my aversion to going with
> Grouped AVPs was concern over reusability of the AVPs, that I would
> have to create a new AVP for each Grouped one to make the semantics
> clear. But I guess if I can get away with using a generic AVP like
> the Framed-IPv6-Prefix AVP the semantics are set by its presence
> within the specific Grouped AVP. I'll rework the document and see
> what I get.
>
> I can't find Framed-IPv6-Prefix AVP in the IANA registry. So I guess
> that's my "common data format" redefined as an AVP.
>
> Tom Taylor
>
> On 17/09/2014 7:12 AM, [e-mail] wrote:
>> Hi Tom,
>>
>> Coming back on the need for a new format ("Common prefix Data
>> format"), could you please explain (or remind me) why this new AVP
>> format would be simpler than creating a Grouped AVP as soon as
>> Prefix or Address can be provisioned?
>>
>> For instance, based on the current draft, the
>> Tunnel-Source-Pref-Or-Addr is defined as a single AVP using the new
>> AVP format defined in this draft:
>>
>> 3.4. Tunnel-Source-Pref-Or-Addr AVP
>>
>> The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD02) conveys either
>> the IPv6 Binding Prefix or the tunnel source address on the CE, as
>> described in Section 2.2.  The Tunnel-Source-Pref-Or-Addr AVP uses
>> the common prefix data format.  The AddressType field MUST be set
>> to 2 (IPv6).  Valid values in the PrefixLength field are from 0 to
>> 128 (full address).
>>
>> This AVP is defined separately from the LW4over6-Binding AVP
>> (which includes it) to provide flexibility in the transport of the
>> tunnel source address from the provisioning system to AAA.
>>
>> But the same info could be also provided as follow:
>>
>> 3.4. Tunnel-Source-Pref-Or-Addr AVP
>>
>> The Tunnel-Source-Pref-Or-Addr (AVP Code TBD0X) is of type
>> Grouped. It MUST contains either an either the IPv6 Binding Prefix
>> or the tunnel source address on the CE, as described in Section
>> 2.2.
>>
>> Tunnel-Source-Pref-Or-Addr  ::= < AVP Header: TBD0X > [
>> Tunnel-Source-Address ] [ Tunnel-Source-Prefix ] *[ AVP ]
>>
>> 3.X Tunnel-Source-Address AVP
>>
>> The Tunnel-Source-Address AVP (AVP Code xxx) is of type Address and
>> specifies the tunnel source IPv6 address on the CE.
>>
>> 3.Y. Framed-IPv6-Prefix AVP
>>
>> The Tunnel-Source-Prefix AVP (AVP Code yyy) is of type OctetString
>> and contains the IPv6 Binding Prefix on the CE.
>>
>> If there is no risk of clash, the existing Framed-IPv6-Prefix AVP
>> could even be reused for the second one.
>>
>> This alternative would have the advantage not to define a new
>> format. I'm not saying that the definition of any new format should
>> be prohibited. But in this case, it seems weird to have to define a
>> new format for combining different types of information that can be
>> already carried in existing AVPs.
>>
>> About the link with Softwires, we need to ensure that the set of
>> information defined in this document has reviewed and somehow
>> endorsed by the WG. Then I think it will become a pure Dime
>> discussion.
>>
>> Lionel
>>
> ...
>
> _________________________________________________________________________________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation. If you have
> received this email in error, please notify the sender and delete
> this message and its attachments. As emails may be altered, Orange is
> not liable for messages that have been modified, changed or
> falsified. Thank you.
>
>