Minutes for DIME at IETF-96
minutes-96-dime-1

DIME IETF96 meeting Notes

    E2E flew through the IESG
        AD to push button
    AVP Security
        No feedback
    LS to IETF
        They will respond that they have an I-D (individual submission) that
        will be accepted as a WG document SA5 will meet at end of August On
        second point, they will have text from Lionel regarding the migration
        to 6733 Maryse Gardella (Nokia) will be at the SA5 meeting and convey
        the LS to the SA5 team
    Overload Status (Steve)
        Need more comments on rate control
        Load Control

       Load algorithm - is there a need to define a load distribution
       algorithm? (No response in room; will continue on mailing list) Another
       question was: do we need to define capacity or only percentage?

    Group Signaling (Lionel)
        Goal is to update the document per Steve’s feedback; get a new draft
        for for WGLC
    4006bis (Yuval)
        G-S-U / U-S-U - Lionel added commentary on the fact that this is merely
        a clarification Zero Grant -
            We need to figure out if there is a protocol spec impact and
            clarify if the receiver of the zero G-S-U that does not understand
            it then we need to add a clarification that if you want to support
            the old method (wait for traffic, send an interrogation) then this
            is okay
        Future Proofing Enums
            (Maryse) Can you clarify why those are to be extended?
                If now we are going to extend the Equipment-Info what is the
                process? Lionel addressed this. In the current process of the
                bis if we come for a new proposal for a value do we still have
                time?  Yes.
            (Stephen) It would be worth considering the privacy implications of
            these new types of  User-Equipment-Info-Extension parameters in the
            draft

            Eventually decided to add a privacy section as part of the 4006bis
            work, not specific to the new IMEI type.

            Authors agreed to update the Security Considerations in general
            Another consideration is the use of RFC 7575 which will update the
            cypher suite (Lionel) Anything related to clarification and slight
            modification is fine.  For any new requirements it is fine to
            incorporate something in a specific way that is already defined or
            in use is okay.  However, we need to keep the changes minimal as
            possible. (Maryse) We stick to the refining process and direction
            but we is the Q-F-U-I.
                Will this be exclude? (Lionel) No. If it expects the old AVP
                then send the extra information (Q-F-U-I).
            (Jouni) Should we add a feature list for this?  We need to consider
            carefully the impact on the client if not supported.
                We will do further analysis on the Q-F-U-I
            Asking for Adoption
                Unanimous on the adoption
            Authors should use the Issue Tracker
    Updated Design Guidelines
        (Yuval) - Concerned about failover which requires the Client to receive
        the error.
            (Lionel) - Will not work.  From the base protocol Point of View you
            should view this as a delivery mechanism.  Unable to Deliver would
            be sent back to the Client and not relying on the redirect
            indication.  That can be used to determine failover.
        (Maryse) - It was her understand that the overload draft was used as an
        improvement for overload information.  The load was introduced to
        anticipate any load information and the overload control is about end
        to end handling of the overload indication.

    Domain masks

    o    (Lyle) DNS usecases are zero rating and parental control. Should be
    used only in non-DNSSEC deployment for privacy issues o    (Stephen) also
    raised concern around privacy, and abuse for other usecases o    (Lyle)
    explained usecase for SDN related bitmasks for IP and flow labels

    Per-flow max bitrate

    o    (Lyle) clarified that “flows” are just IP flows (5-tuples), not
    replacing application level QoS. Shallow packet inspection should be used
    where DPI is not needed

    Policy Groups

    o    (Lyle) gave the experimental background leading to the formation if
    the idea o    (Lyle) explained the different concepts (base-names, rules
    bitmaps, domains, match types, membership assignment) and how the map to
    procedures with rules and solve inefficiencies with current approach to
    rule system

    Predicted units

    o    (Lyle) in NFV the client should be proactive. Currently it does not
    have a good way to predict future load o    (Lyle) the server can be a
    better point for predicting load based on usage profile of subscriber. And
    information should be sent back to client o    (Lyle) current proposal
    based on bytes should be modified to include bits/sec, time-o-f-day infor
    and other things that are more useful for load prediction o    (Stephen)
    was concerned that usage profile is usually information that is not sent
    back to client, and might be privacy risk

    (Lionel) was asking how and where the above AVPs are going to be adopted?

    o    (Lyle) in NASREQ, by operators doing custom stuff, maybe by other
    groups (3GPP CT4)

    (Lionel) want to explore using policy groups as a mechanism for system
    configuration and not just subscriber provisioning

    o    (Lyle) maybe added to group update work

    Warp up

    o    (Jouni) No new charter item
    o    (Jouni) 4006bis and group signaling could be finalized over mailing
    list and virtual meetings o    (Steve/Lionel) security related work will
    require more effort, may need more face2face