Hi Woj,
On 2013-7-11, at 下午10:43, Wojciech Dec wrote: > Hi, > > > Yes, there was a long thread started by Tomek. Given that the option is > applicable beyond MAP a *suggestion* was to rename it. I'm personally ok > either way. The "Softwire46" option is the currently proposed name. [Qi] At the first glance, I thought it stood for "Stateless46" option... (sorry for missing the discussion) > > > > - Flags: The flags field will be removed from the options. To accomplish > > this, what was previously known as the BMR/FMR option, which was using the > > flag to make the difference, will now be recast as two separate "Basic > > Rule" and a "Forwarding Rule" Options. > > From my understanding, the 'flags' are referred to those in MAP Rule Option > (rule-flags), right? Or do you mean the flags in MAP Container Option will > also be removed? > > All flag fields removed. [Qi] If so, how could a MAP node finds out it should work as MAP-E or MAP-T? Or we can take this MAP DHCP draft as "MAP-E DHCP"? > > > - A new sub-section intended only for clients using the MAP algorithm will > > be introduced, and will describe how the options apply to MAP provisioning. > > I'm not quite sure about the content that you plan to provide. IMHO, the > DHCPv6 client (not a MAP DHCPv6 client) is only able to handle the DHCPv6 > related interactions, rather than MAP related interactions. If this part is > about how the client side uses the MAP options, maybe the MAP-E or the > Unified CPE is a more proper place to go, IMHO. > > Well, the MAP Port Parameters option is clearly only applicable to a client > that understands what it means. While having a separate, standalone 1-page > draft for this single option is doable, it does become to look like > unnecessary bureaucracy. DHCP Options are options after all... [Qi] So this sub-section is about the behaviors of the client after receiving the MAP Port Parameters Option? Best Regards, Qi > > Thanks, > Woj. > > > > Best Regards, > Qi > > > On 2013-7-8, at 下午6:18, Wojciech Dec wrote: > > > Hi All, > > > > I've begun preparing the next ste of changes to the DHCP MAP option draft, > > and would like to highlight the main changes. > > > > - Naming: The name of the option will be changed, tentatively, to > > OPTION_S46_*. This it in line with the recognition that there is wider > > applicability of the options. Furthermore the "Mapping" term will be > > removed from the text, except when describing their use with MAP algorithm. > > - Default Mapping Rule: The DMR option will be removed, to allow the re-use > > of the existing AFTR option, if desired and when applicable. > > - Flags: The flags field will be removed from the options. To accomplish > > this, what was previously known as the BMR/FMR option, which was using the > > flag to make the difference, will now be recast as two separate "Basic > > Rule" and a "Forwarding Rule" Options. > > - Some of the generic DHCP requirements about known or unknown processing > > appear to actually conflict with DHCP practice and will be changed, eg an > > unknown sub-option should not lead to the entire option being discarded. > > - A new sub-section intended only for clients using the MAP algorithm will > > be introduced, and will describe how the options apply to MAP provisioning. > > - Various other editorial changes to bring the text into shape. > > > > If you have any initial comments, reactions to the above, please let us > > know. > > > > Regards, > > W. Dec > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
