Hi Suresh, Please see inline below.
Thanks, Ian > On 10. Jan 2019, at 15:05, Suresh Krishnan <[email protected]> wrote: > > Suresh Krishnan has entered the following ballot position for > draft-ietf-softwire-yang-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I would have thought putting in a prioritization mechanism (like RFC8026 does) > for ordering the different mechanisms would have been useful in this YANG > module in order to configure the CE. Was this something that was considered? > > [if - The intention of RFC8026 was to give greater control when you have multiple softwire mechanisms in use (e.g. during migration) and CE devices with unknown capabilities (different age devices, user supplied etc). It gives a way of a CE side implementation of a stateless (in the DHCP server) prioritisation policy (throw enough config and the best available one sticks) Due to Netconf/YANGs much greater interaction - capabilities exchanges, features, deviations etc., it’s easier to configure specific devices with only the config they are capable of and you want them to run, so you don’t get the case where the host has multiple configurations to choose from. ] _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
