Re: [Dime] Notes from IETF95 dime meeting

[<[e-mail]>]

thx a lot!

Lionel

> -----Message d'origine-----
> De : DiME [mailto:[e-mail]] De la part de A. Jean Mahoney
> Envoyé : vendredi 8 avril 2016 19:42
> À : [e-mail]
> Objet : [Dime] Notes from IETF95 dime meeting
> 
> Below. Pieces I missed are marked with ellipses (...)
> 
> Jean
> 
> -----------------------------------------------------------------
> IETF-95 DIME
> 
> 1000-1200  FRIDAY, April 8, 2016, Morning Session I (120 min) meeting room:
> Quebracho A
> 
> Chairs:
> Jouni Korhonen <jouni.korhonen at broadcom.com> Lionel Morand
> <lionel.morand at orange.com>
> 
> 
> 10:00 - 10:10, Preliminaries (5 minutes)
> ------------------------------------------
> Audio/Video & Remote Presentation Debugging
> 
> Presenter: Jouni
> Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-4.pdf
> 
> Note Takers - Jean Mahoney
> Jabber scribe - Jean Mahoney
> Jabber log - http://www.ietf.org/jabber/logs/dime/2016-04-08.html
> 
> 
> slide 1: Title
> 
> slide 2: Note Well
> 
> slide 3: Agenda 1/2
> 
> slide 4: Agenda 2/2
> 
> 
> 10:10 - 10:20, WG Document Status (10 minutes)
> ------------------------------------------
> 
> Presenter: Jouni
> Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-4.pdf
> 
> 
> slide 5: WG Status Update (1/2)
> 
> * draft-ietf-dime-e2e-sec-req-04        --> in IESG
> * draft-ietf-dime-drmp-04               --> in IESG
> 
> slide 6: WG Status Update (2/2)
> 
> * draft-ietf-dime-group-signaling-06    --> In WG --> WGLC?
> 
> Received comments from Steve Donovan, which will be covered in the
> meeting.
> 
> * draft-ietf-dime-load-02               --> In WG --> WGLC?
> * draft-ietf-dime-doic-rate-control-03  --> In WG --> WGLC?
> 
> * draft-ietf-dime-agent-overload-04     --> In WG --> WGLC?
> * draft-ietf-dime-ovli-10               --> RFC7683
> 
> slide 7: Milestones
> 
> 
> Dime working group draft discussions (0 minutes)
> -------------------------------------------
> 
> Presenter: Steve Donovan
> Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-3.pdf
> 
> 
> slide 8: Next steps
> 
> Jouni - How far along is the agent-overload draft?
> 
> Steve - it's ready for WGLC.
> 
> Jouni - Then leave the draft as-is. All drafts can go to WGLC about the same
> time.
> 
> Lionel - What's the issue with SourceID?
> 
> Steve - The agent-overload draft defines the payload for it. The node that
> inserts the OL report or the node that advertises support. It's just a
> DiameterID. In the case of load - it's the node that inserted load report.
> 
> Lionel - Is it a different type of id depending on the what you're sending?
> 
> Steve - It's meant to be generic. I'll make sure it's clean.
> 
> 
> slide 14: Next Steps
> 
> Lionel - maybe we should not send everything to WGLC at the same time,
> but send them in rapid succession. Start with the dime-load draft?
> 
> Steve - That has dependencies on the agent-overload draft.
> 
> Jouni - start with the document with most dependencies.
> 
> Steve - agent-overload, then dime-load.
> 
> Lionel - We don't have a dependence yet in 3GPP. Next step will be to rely on
> the AVP in the Release 14 timeframe, so we'll need something soon. Need to
> review agent-overload and dime-load.
> 
> Steve - What about getting an early assignment for the AVP number?
> 
> Lionel - I'll ask, but I don't think it's necessary. We have time.
> 
> 
> ACTIONs: Review/WGLC agent-overload first since more drafts are
> dependent on it. Then move on to dime-load review/WGLC, then the rest of
> the overload-related drafts.
> 
> 
> ---------------------------------------
> Group signaling feedback
> 
> Presenter: Marco Liebsch
> Draft: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/
> Slides: None posted
> 
> Slide: Title
> 
> Thanks for Steve's comments
> 
> Slide:  RFC2119 consistency
> 
> Steve - Capitalization issues - 2119 usage.
> 
> Marco - we need to determine if the statements are mandatory or not.
> 
> 
> Slide: Server rejection of group assignment
> 
> Steve - It's not clear. Are you talking about general Diameter requests or
> requests for group allocation? Could be read either way.
> 
> Marco - Even if server rejects group assignment, the server could handle the
> Diameter session. It's for assignment of the group. Need to make it clear in
> the text.
> 
> Lionel - It's in the sentence above.
> 
> Steve - There's a few other places where it needs to be clearer.
> 
> 
> Slide: Server partial success of session group assignment
> 
> Marco - Didn't think about this case. What would cause one to fail but
> another to succeed? Resource allocation?
> 
> Steve - that's the fundamental question. Resources, policies. Server can
> insert a session into a group based on policy. Multiple groups request in one
> request. Resources is fundamental.
> 
> Marco - From the signaling point of view. The client asks for assignment to 3
> groups, of which, 2 allocations are set and the 3rd is cleared (not successful).
> How does the client react? Or does it reject all sessions?
> 
> Steve - the last sentence implies all or nothing.
> 
> Marco - that should be fine. For all 3 group.
> 
> Lionel - The Session-Group-Info AVP will be there for all 3 groups. For the
> failed one, the flag is cleared.
> 
> Steve - Add words to the effect that each AVP will present the status of each
> request. The words "as received" implies that it's one-to-one and can't be
> changed.
> 
> Lionel - It's up to the client what to do - whether it wants to go on with a
> partial assignment or close the session.
> 
> Steve - makes sense. Once a session assignment request fails, the session
> request must not be in group. This is a corner case - have to clarify that
> 
> Lionel - client needs to manage each individual request for group assignment.
> And need to say what do to when not successful?
> 
> Steve - yes.
> 
> 
> Slide: Client failure at server's session group assignment
> 
> Steve - Agree that it should be rare. There's a policy concern. The client
> would not have requested it in first place. It has resources when it makes the
> request. What if the state saved in client is different than what's saved in the
> server?  Is it bad to have inconsistent state?
> and if so, how do you sync state?
> 
> Lionel - Especially if you have multiple groups. One spec group and...
> and if it was not maintained in the client, it would fail for at least one session.
> Clarify this.
> 
> Marco - should the client terminate the session if it can't handle the group
> assignment?
> 
> Lionel - "should" would be enough, but should clarify it. Avoid corner cases.
> There's not a concept of an optional assignment. The client should be able to
> comply to a request from the server or renegotiate the session.
> 
> 
> Slide: "Hard" server rejection of server
> 
> Lionel - I don't see the problem for this one. For this request the server can't
> do group assignment. The session will be a single session.
> 
> Marco - the server includes the Session-Group-Info AVP with the flag
> cleared.
> 
> Lionel - if it's a legacy server, it doesn't send back anything at all.
> 
> Steve - this is a protocol error. It's not constructing protocol error.
> RFC doesn't have to handle this case.
> 
> Lionel - This server doesn't support it at all. Once the server has been
> updated to support the feature, but doesn't want to use it with these clients
> is another case.
> 
> Marco - Should be known from other session using capabilities vector.
> 
> Lionel - if you are a client, proxy, so on. Have e2e negotiation. I'll check that
> it's consistent in text.
> 
> 
> Slide: Use of Group-Response-Action AVP
> 
> Steve - a fundamental question - and it's not clear - You have a group
> in a server with 1000 sessions. Which session does the server chose to
> send the update request to? The first one isn't an anchor or something?
> 
> Marco - No
> 
> Steve - Add text to clarify
> 
> Lionel - any sessionID can be used can effect the session.
> 
> Steve - Why all groups that this sessionID is part of. Why all groups?
> that's pretty complex.
> 
> Lionel - we like to complexify everything. Multiple groups with similar
> ... Creating a request to put session in multiple groups. Charging
> characteristics with few differences. One characteristic is shared by
> all groups.
> 
> Steve - but you can have a group of all groups. It's complex - you have
> to search... it's doable. It's seems strange when you can create another
> group. If you are defining a metagroup -
> 
> Lionel - Can discuss on ML whether to keep the ALL_GROUPS.
> 
> Marco - it's meant to be all groups in the request. You can indicate one
> or multiple groups in the request. If the session is in multiple groups
> - for instance Change QoS in these groups.
> 
> Steve - need to define impacted groups.
> 
> Lionel - Move on, move to ML.
> 
> 
> 
> Slide: Next
> 
> Marco - do we use tracker?
> 
> Steve - look at state consistency question closely. Things can get out
> sync it seems.
> 
> 
> Individual draft discussions (15 minutes)
> -------------------------------------------
> 10:20 - 10:35 End to end security solution, Jouni (15min)
>    Draft: https://tools.ietf.org/html/draft-korhonen-dime-e2e-security-03
>    Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-0.pdf
> 
> 
> slide 7: Protecting AVPs
> 
> Jouni - JSON is kinda ok. Is CBOR/COSE more appropriate?
> 
> Steve - we have some Diameter AVPs with an encoding. We would translate
> into JSON or CBOR and then encrypt?
> 
> Jouni - just two new AVPs.
> 
> 
> slide 8: Signed-Data AVP
> 
> Lionel - what about multiple instances of the same AVP?
> 
> Jouni - you can have that. They have different signatures.
> 
> Lionel - you sign each AVP?
> 
> Jouni - yes
> 
> 
> slide 9: Encrypted-Data AVP
> 
> Steve - it's not addressed in this draft, that it cannot be used with
> applications since encrypted AVPs.
> 
> Jouni - The middlebox has to look at them.
> 
> Steve - you could allow the encryption of routing headers if hop-by-hop.
> 
> Jouni - but we're looking for e2e.
> 
> Lionel - What about encrypting only AVP content?
> 
> Jouni - Why reveal anything about the AVP? You can always encrypt
> content of the AVP unless there's structured content defined.
> 
> Lionel - Username cannot be encrypted. Domain info.
> 
> Jouni - You'll need a new app. You don't need username for routing in 3GPP.
> 
> Lionel - if you can encrypt the contents--
> 
> Jouni - unless you have strict format of the AVP. NAI. Will fail at some
> middle box. It needs to be rehashed.
> 
> 
> slide 11: Anyway..
> 
> Jouni - pull up the presentation at IETF 85 for good examples.
> 
> Jouni - does 3GPP want this?
> 
> Lionel - likely, yes. No 3GPP requirements yet since the main interfaces
> have been internal. But they are asking more questions about security
> and integration. There are security questions around Charging Info. No
> TR yet. It's a MUST from my point of view. We just need people to work
> on it. People with more knowledge of security would be helpful.
> 
> Jouni - There's just one guy who has the experience with both security
> and Diameter - Hannes.
> 
> Lionel - maybe we ask for Hannes' support.
> 
> Jouni - Please review the document.
> 
> Lionel - we can use this doc as a starting point for WG discussions.
> 
> 
> 
> Other discussions topics (20 minutes)
> -------------------------------------------
> 
> 10:35 - 10:55 Protocol errors, 'E' bit and answer command CCF grammar,
> Lionel (20min)
>    Draft: N/A
> 
> slide 9: Basic assumption
> 
> Lionel - Must be compliant with 7.2 when it's a protocol error.
> 
> Jouni - what's the real-life problem?
> 
> Lionel - Redirection is a good example. EAP request in Answer has
> redirect indication. Vendors say you're not compliant. They just--
> 
> Jouni -  that's just bad implementation.
> 
> 
> slide 10: Proposed way forward
> 
> Jouni, as individual - it's not broken specification wise. There's bad
> implementations. We had an earlier situations where we had to clarify
> the base. I wouldn't update existing RFCs. If there is an issue, then a
> BCP or informational doc on how to write your spec would work. I
> wouldn't fix existing specifications.
> 
> Jean - What about updating the Application Guide?
> 
> Jouni - there are some corner cases in the App Guide. .
> 
> Jouni as chair - I need to get the sense that this really is an issue.
> Anyone seen this in the field?
> 
> Lionel - This is from 3GPP.
> 
> Jouni - they can send it to the mailing list.
> 
> Lionel - Yes
> 
> 
> slide 11: Your view?
> 
> Lionel - could see what to put in the revision. Highlight what's
> missing/unclear.
> 
> Lionel - It is difficult for new people to get involved in this group.
> It's not clear for new people.
> 
> 
> Wrap-up and Next (10 minutes)
> --------------------
> 11:00 - 11:10 Next Steps: WG Chairs & ADs (10 minutes)
> WG Goals/Milestones status, next steps
> 
> Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-4.pdf
> 
> slide 8: Next Step/Charter
> 
> Jouni - not looking for new work just for the sake of extending
> diameter. Just security and the e-bit clarification.
> 
> Lionel - what about topology hiding? any willingness to work on this issue?
> 
> Steve - it's not an IETF problem. Is anyone asking for it?
> 
> Lionel - not anymore. But it was brought up during overload discussions.
> 
> Steve - GSMA has topology-hiding requirements.
> 
> Lionel - I can check.
> 
> Jouni - Actions before next IETF:
> 
> ACTIONS:
> Progress all the overload/load docs. Lionel will assign reviewers for
> the documents.
> Lionel - e-bit handling
> Jouni - to initiate discussion on e2e sec and get secdir people.
> Jouni -  WG to use the issue tracker for WGLC comments.
> 
> slide 9: AOB?
> 
> No further business
> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.