Re: [mif] Proposal for circumventing Huawei IPR

[Terry Manderson <[e-mail]>]

Stjepan and All,


As the responsible AD I would like this thread to stop here.

A Working Group can either choose to accept (by rough consensus)
technology that is encumbered by IPR or not accept that technology. Once
rough consensus is reached on an IPR disclosure, all WG participants are
expected to abide by that in dealing with the encumbered technology in the
WG.

The WG reached rough consensus in November 2015 to drop
draft-ietf-mif-mpvd-dhcp-support
(https://www.ietf.org/id/draft-ietf-mif-mpvd-dhcp-support-02.txt) with the
IPR claim at https://datatracker.ietf.org/ipr/2648/

Any participant may suggest new alternative technologies for the WG to
consider via the known methods.

Cheers
Terry

On 17/03/2016, 8:56 PM, "mif on behalf of Stjepan Groš"
<[e-mail] on behalf of [e-mail]> wrote:

>Hi everyone,
>
>here is the proposal on how to circumvent Huawei's IPR claim so that we
>are able to use DHCP for what it was designed for, node configuration. As
>an added bonus, we also solve the problem of multiple concurrent DHCP
>servers on a single local network.
>
>First, let me state few assumptions:
>
>1. The alleged problem with Huawei's IPR claim is that it includes an ID
>in DHCP server's response and for that reason this group abandoned the
>approach.
>
>2. In the talks about the exact format of ID there were suggestions to
>use only UUID. Based on my experience while implementing PvD support in
>NetworkManager (https://github.com/sgros/MIF_NetworkManager)
> this is good approach because it simplifies things a lot.
>
>3. DNS can be used for service discovery, but other mechanisms (and
>descriptions) should be allowed as well. Additionally, service
>description should include reachability definitions.
>
>4. ID is used only for identification purposes of some specific PvD, and
>possibly as a parameter in a service discovery (even though DNS approach
>doesn't do that, but e.g. HTTP approach might).
>
>So, what I propose is NOT to send ID in responses but only a container
>option with a set of options that belong to a single PvD instance. ID is
>then calculated based on the PvD parameters, e.g.
>
>MD5(NETWORK_PREFIX, NETWORK_PREFIX_LEN, DNS_SERVERS, DNS_DOMAINS)
>
>Concrete set of options/parameters is to be determined but it is
>intention to uniquely identify PvD, not PvD instance. In this way client
>will be able to distinguish PvDs, and if necessary client and server will
>agree on unique PvD ID for each PvD.
>
>Few additional notes/comments:
>
>1. This can be calculated for implicit, as well as explicit PvDs. Note
>that in the mentioned implementation I was using this approach to try to
>differentiate implicit PvDs sent in RA messages.
>
>2. Part of PvD CO option might be an option that specifies how to do
>service discovery. This would allow flexibility. This option should also
>be included in ID computation.
>
>3. For an added flexibility (if its really needed as it complicates
>things!) PvD CO option might specify which options to include or not
>include in the calculation of ID.
>
>4. After node learns about some PvD it can request specific PvD by
>including its calculated PvD ID in request. The response will be without
>ID, obviously! Huawei IPR claim doesn't cover this case.
>
>5. This would solve the situation of multiple DHPC non-PvD aware servers
>on a local network. By calculating ID of each reposnse client can
>determine if those responses are alternative (failover) or concurrent and
>react appropriately. The same mechanism might
> be used for RA messages.
>
>6. The approach will work for local network configuration (PvD specific
>for a certain local network) as well as for PvD's specific for providers'
>global networks (i.e. sending "video only" PvD to all its customers that
>are on different IPv6 subnetworks).
>
>SG
>
>P.S. Just as a note, I use of two distinct terms "PvD" and "PvD
>instance". "PvD instance" includes specific host information like
>concrete IP address, while "PvD" is a set of "PvD instances" valid on a
>certain network. To even better describe the difference,
> it should be noted that RAs send PvDs, while DHCPv4/DHCPv6 resposnes
>send PvD instances.