Minutes IETF104: dhc
minutes-104-dhc-01

DHC WG Agenda for IETF-104 (Prague)

Date: Wednesday, 27 March 2019, Morning Session I 0900-1100 (GMT+1)
Location: Karlin
Chairs: Tomek Mrugalski & Bernie Volz
Secretary:
Presentations materials:
https://datatracker.ietf.org/meeting/104/materials.html#wg-dhc

Summary:

The following presentations / discussions took place during the session:

- "Link-Layer Addresses Assignment Mechanism for DHCPv6 (refresher)" about
  draft-bvtm-dhc-mac-assign, by Bernie Volz. This had failed an adoption call
  recently as no one commented either for or against. After the presentation
  and discussions, there was interested in retrying the adoption call. The
  chairs will shortly initiate the adoption call and need comments to the
  mailing list.
- "SLAP quadrant selection options for DHCPv6" about
draft-bernardos-dhc-slap-quadrant,
  by Carlos J. Bernardos. After some discussion, interest in doing an adoption
  call. Chairs will initiate shortly.
- "YANG DHCPv6 update" about draft-ietf-dhc-dhcpv6-yang by Ian Farrer (remote).
Work
  has slowed down as several authors have lost interest. Discussed how to
  proceed. Ian to try to pull interested parties together to reboot effort.
- "Future of the DHC WG, Chairs" by Tomek Mrugalski. Consensus seems to be to go
  dormant for a while after finishing work to advance RFC8415. One question as
  to whether temporary addresses might be something to deprecate from RFC8415.
- "Problem Statement of Multi-requirement Extensions for DHCPv6" about
  draft-ren-dhc-problem-statement-of-mredhcpv6 by Lin He. Consensus was that
  this information on extending DHCP functionality is useful especially in
  light of future of WG. Call for adoption to be started.

Details:

 1. Administrativia (Agenda Bashing, WG Status, ...), Chairs - 10 minutes
 2. Link-Layer Addresses Assignment Mechanism for DHCPv6 (refresher), Bernie
 Volz - 10 minutes
    draft-bvtm-dhc-mac-assign
    Bernie presented the slides.
    See
    https://datatracker.ietf.org/meeting/104/materials/slides-104-dhc-link-layer-addresses-assignment-mechanism-for-dhcpv6-refresher-01
    Francis Dupont asked why the call for adoption failed. Bernie responded
    that we had
     zero responses.
    Tim Chown asked if there are any other proposals for a protocol (such as
    from IEEE). Bernie answered that he's not aware of one, but believes IEEE
    is working on one. Suresh (with AD hat off and remotely): supports this
    work Erik Kline: Question about sending many addresses, concern about pkt
    size (misunderstood
      the pkt format).
    Suresh: Does not believe IEEE has an alternative
    Jinmei: reviewed the draft, but was unsure about if the usage model.
    Willing to review
      it periodically if adopted.
    Tim asked if about some of the use cases and some discussion followed.
    Mic suggestion: the people interested in this usage mode should speak up
    during adoption
 3. SLAP quadrant selection options for DHCPv6, Carlos J. Bernardos - 15 minutes
    draft-bernardos-dhc-slap-quadrant
    Carlos presented the slides
    See
    https://datatracker.ietf.org/meeting/104/materials/slides-104-dhc-slap-quadrant-selection-options-for-dhcpv6-00
    +00:22:00: Carlos presenting Tim Winters: supports working on both
    documents, but keep as separate, try to advance
      them at the same time
    Tim Chown: agrees with Tim Winters
    Suresh: also supports another adoption call
    Chairs will initiate WG Adoption call for both link-layer documents.
 4. YANG DHCPv6 update, Ian Farrer/Tomek Mrugalski - 10 minutes.
    draft-ietf-dhc-dhcpv6-yang
    +00:36:00: Ian presenting remotely.
    Slides at
    https://datatracker.ietf.org/meeting/104/materials/slides-104-dhc-dhcpv6-yang-model-update-00
    Ian requests those with issues on the issue tracker review recent changes
    to confirm
      their issues resolved.
    Bernie suggested we use approach similar to DNSOPS, define the basic DHCP
    data which
      can be used by anyone. Previous (~2000) attempts to do LDAP model failed
      because one model doesn't work as servers have different models. So,
      allows everyone to use fundamental building blocks to define their model.
    Ian responded that some options are not needed in the model (i.e., IA_NA).
    He feels a
      full model is mode useful as concepts are fairly uniform. Would like to
      know if current model does not work for a specific implementation and why.
    Bernie says that he wasn't expecting to model all options - just those that
    are configured. Ian suggests anything in an Information-Request. Bernie
    responds that it isn't that simple - take prefix exclude option. Tim Chown:
    There is a router base model that defines some of the options, not all.
    Questions
      if model would be useful.
    Tomek: Kea model is a bit different than the draft. Believes we can come up
    with a common
      demonitor model. Believes that doing bits and pieces (such as DNSOPS) is
      a last resort; would prefer a full model.
    Bernie beleives you can do basic components model, and then continue work
    on full model. Richard Peterson: focus the scope on common work. There will
    always be vendor-specific
      Yang models.
    Bernie: By doing basic items (i.e., prefix, ...) we can start and then
    build full models. Ian: Building blocks are pretty common; like to see a
    model with vendor customizations.
      Asks Bernie if there's anything in current model that would make this not
      doable.
    Bernie: Not sure, need to review model as it has been a while.
    Bernie: You are looking for help.
    Ian: Is anyone willing to work on this?
    Richard: as an operator willing to review and eventually deploy this (with
    softwire models). Ian asked if Richard would be willing to review. Ian to
    solicit interest/potential authors to work on this and determine course of
    action. Michal Nowikowski of ISC volunteered to work on document.
 5. Future of the DHC WG, Chairs - 15 minutes
    +00:58:00: Tomek presenting
    See
    https://datatracker.ietf.org/meeting/104/materials/slides-104-dhc-future-of-the-dhc-wg-01
    Jinmei: What about IA_TA's - should they be removed (deprecated)? Will we
    have any
      implementations?
    Bernie: Does not believe IA_TAs were deprecated in RFC8415.
    Tim Winters: His recollection was that IA_TAs were left in but not
    "recommmended". Tomek: As if interoperatibility was tested. Tim Winters:
    Doesn't beleive this is a major issue as some do not implement IA_TA
      and it is optional.
    Suresh: Supports WG going Dormant after RFC8415 is Internet Standard.
    Tim Chown: What we don't have is a list of what may be needed? Is there
    more protocol
      work? What about option reviews.
    Bernie: We have IANA expert review for DHCPv4 & DHCPv6 options. Options are
    now done
      in the other WGs.
    Tim Chown: What about unforseen items? Use Int-Area WG?
    Bernie: Yes, Int-Area would be a good backstop.
    Tim Chown: Thinks that going Dormant for a while to see if anything springs
    up before
      closing WG.
    Steve Morris (ISC): Follow model of TCP Maintenance WG? Avoid issues with
    DNSEXT and
      DNSOP now doing lots of DNS protocol work
    Ian: There may be an interim state, used by Softwire - don't accept new
    work, finish
      existing.
    Bernie: Doesn't feel setting up new WG which does what old one did.
    Ian: But you need a pratical way of handling things that come up.
    Shane Kerr: Don't use DNS model as DNSSEC interrupted other DNS work, as
    that was
      driven by getting DNSSEC deployed.
    Tomek: having a deadline of a year to finish current work will be
    motivational. Tim: +1 for the one year deadline Shane: Don't use DNS model
    as DNSSEC interrupted other DNS work. Suresh (via Eric V): Say to Tim - yes
    this would be the backup plan. Bernie: We'll see what happens between now
    and when we complete main goal (advance
      RFC8415) as things may change.
 6. Problem Statement of Multi-requirement Extensions for DHCPv6, Gang Ren - 10
 minutes
    draft-ren-dhc-problem-statement-of-mredhcpv6
    +01:15:00: Lin He presenting
    See
    https://datatracker.ietf.org/meeting/104/materials/slides-104-dhc-problem-statement-of-multi-requirement-extensions-for-dhcpv6-00
    Bernie: This is individual-submission and Informational track. It points
    out how to
      extend servers.
    Tim Chown: Feels information is useful, especially if WG is shutting down.
    Gang Ren: Most of the work is related to address generation.
      Would like to see requirements for servers to support this
    Tomek: Supports work, while information available in product documentation,
      publishing here would be useful..
    Francis Dupont: Unclear - something about a conference in May?
    Tomek asked about interest (about 8 raised hands). Will start adoption call.

WG ended at +01:28:00.

YouTube video of session available at
https://www.youtube.com/watch?v=EVpV3PNVyhM.