Subject: [Dime] dime 94 meeting notes - raw

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 5 Nov 2015 10:10:47 +0900

Hi all,

Below are my raw notes from the meeting. Comments I missed are marked 
with ellipses (...) or ajm.

Thanks,

Jean

dime 94

1300-1400  TUESDAY, November 3, 2015, Afternoon Session I (60 mins)
meeting room: Room 413
Jabber room: dime at jabber.ietf.org

------------------------------------------
13:00 - 13:05, Preliminaries (5 minutes)
Presenter: Lionel Morand
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-dime-0.pdf

Note taker and Jabber scribe: Jean Mahoney

Lionel - Jouni was not able to make it to Yokohama.

slide 1: Title

slide 2: Note Well

slide 3: Intellectual Property

slide 4: Agenda 1/2

slide 5: Agenda 2/2

------------------------------------------
13:05 - 13:10, WG Document Status (5 minutes)
Presenter:  Lionel Morand
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-dime-0.pdf

slide 6: WG Status Update (1/2)

draft-ietf-dime-ovli-10 - RFC 7683
draft-ietf-dime-4over6-provisioning - RFC 7678
draft-ietf-dime-congestion-flow-attributes - RFC 7660

slide 7: WG Status Update (2/2)

* draft-ietf-dime-group-signaling-05	--> In WG --> WGLC?
* draft-ietf-dime-drmp-01		--> In WG --> WGLC?
* draft-ietf-dime-load-01		--> In WG --> WGLC?

Lionel - Needs more reviews

* draft-ietf-dime-doic-rate-control-02	--> In WG --> WGLC?
* draft-ietf-dime-agent-overload-03 	--> In WG --> WGLC?
* draft-ietf-dime-e2e-sec-req-03	--> In WGLC --> Write Up

Lionel - I've done the doc shepherd writeup. I think that some points 
need to be clarified/corrected. Jouni will take the discussion to list. 
May not need new WGLC, but will need a new version.

-------------------------------------------
13:10 - 13:20 Diameter Request Message Priority
Presenter: Steve Donovan
draft: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-dime-1.pdf

slide 1: Title

slide 2: Changes in -01

slide 3: Changes in -01 already agreed upon

Steve - some of these bullet items have been overturned by recent 
postings to the list.

slide 4: Changes in -01 already agreed upon

slide 5: Open Questions

No one had comments on the number of priority levels.

Steve - the current value of Default Priority in the draft is 14, the 
slide has a typo. Is there consensus on this?

Ken Colbert - consensus. But if you move the default to not lowest, 
there's not a 1-1 correlation. 3GPP doesn't have concept of lower or 
scavenger values.

Steve - There's the case - s6a.

Lionel - Need to provide a indication that the message is informational.

Ken - you have 10 from IETF and 15 from 3GPP.

Martin Dolly - This is visible to the agents. The other AVP is not. 
Don't get caught up on the number.

Steve - the semantics are different than 3GPP. If an app needs to relate 
the two priorities, it needs to define the mapping.  Back to slide 3 - 
SHOULD/MAY

Ken - I advocate SHOULD. It's good to have a known quantity when it 
ships with the box. Vendors shy away from implementing MAYs - something 
they don't have to code and test.

Lionel - my comment was along same line. We're mixing 2 points. The main 
point is to give higher priority to cases like emergency. If signaling 
between networks. It should mean - highest priority. .... No priority 
should be 10, but the operators can do what they want.

Jay Lee - ... We don't need to ...
[ajm: Jay had 2 points, but I missed them because of interacting with 
the Jabber room]

Lionel - we want to avoid having vendors doing whatever they want. The 
SHOULD doesn't preclude sending another value, but you should interoperable.

Martin - having a SHOULD is good. Any of the parameters will have to be 
mapped into SLAs. Having the same value out of the box is good.

Jay Lee - if you use SHOULD, it could be confusing. It's mandating. But 
it can be overwritten.

Lionel - In the text we can clarify - you receive the request, but it 
doesn't say how you process it. Here you can put the SHOULD. If you 
don't have a reason to change the default, don't change it. You have a 
clear recommendation.

Steve - then there's the note.

Jay - it's going to be overwritten anyway.

Steve - it's not overwritten - it's a message that has no priority.

Jean-Jacques Trottin - If an operator has good reason to use another 
value than 10, it may use another value, otherwise it will use the 
default value.

[ajm: I also missed some stuff here because of standing in queue.]

Lionel, as chair to the room - is there a real concern about SHOULD?

No one had comments.

ACTION: Repeat the question on the mailing list.

slide 6: Next Steps

Lionel - ... Need to confirm on list.

Steve - Strong support on the list.

Lionel - can go to WGLC after updates.

-------------------------------------------
13:30 - 13:40 Diameter Load Control
Presenter: Steve Donovan
draft: https://datatracker.ietf.org/doc/draft-ietf-dime-load/
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-dime-2.pdf

slide 1: Title

slide 2: Changes in -01

slide 3: Theory of Operation

slide 4: Load AVPs

slide 5: Next Steps

Lionel - Needs review. This is high up on 3GPP list - Release 13 item.

Steve - WGLC before end of year. hopefully.

Lionel - it's a study item for 3GPP load control mech. Need additional 
reviews, we can't review and chair at same time.

Steve - if you do a review and agree with everything, comment on the list.

-------------------------------------------
13:40 - 13:50 Diameter overload control extension
Presenter: Steve Donovan
draft: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-dime-3.pdf

slide 1: Title

slide 2: Agenda

slide 3: Changes in -03

slide 4: Next Steps

Steve - For review - make sure there's no peer report stuff in draft. If 
you want the rate feature, need to ensure this doc is done also.

Lionel - Are there any open points or assumptions identified in the 
draft to trigger discussion?

Steve - we went through that on the -01 version. I don't know of any 
issues. Just need to decide if it's ready for WGLC.

Lionel - send comments to the mailing list and not directly to Steve. 
Even if the comments are between authors or during face-to-face 
meetings. It's useful for the chairs and ADs.

-------------------------------------------
Rate Abatement Algorithm
Presenter: Steve Donovan
draft: https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-dime-4.pdf

slide 1: Title

slide 2: Status

slide 3: Open Question

Steve - The draft's second section is pulled nearly verbatim from SIP 
rate control.

One open issue - with DOIC, the loss algorithm can be carried in host 
and realm reports. The rate algorithm can only be carried in the peer 
report. Does it make sense to carry in host? It would only work if 
server selection is being done by a client. It doesn't make sense to add 
it to realm.

slide 4: Next Steps

Steve - It hasn't had as much review. Please review.

Lionel - any reaction to the open issue?

Steve - there's been a little bit of discussion on list.

Lionel - reactivate this one and confirm assumption. Please comment. Use 
the tracker?

Steve - fine with me, it worked well with DOIC because the number of 
issues.

Lionel - it's easer to find issues in the tracker. Use the tracker. Even 
for editorial.  for all the drafts.

ACTION: Reviewers should use the tracker to capture draft issues, even 
editorial ones.

-------------------------------------------
13:50 - 13:55 Diameter Group Signaling
Presenter: Lionel
draft: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/

Lionel - Marco is not here. There's been no progress on this. Where to 
go with this one? Steve commented on it. There were some doubts about 
the usefulness of the mechanism originally, then some said that it was 
good to do. There's some 3GPP discussion about this topic. Please 
review. On the mailing list, I'll give a deadline of December. If no 
reviews by then, then there would be no interest from the working group, 
and we won't go forward with it.

Steve - I haven't reviewed -05. If the work is done in 3GPP, I have a 
concern that the agent impacts may not be properly addressed since 3GPP 
does not acknowledge agents.

Lionel - 3GPP wants to reuse specification. It would be good to define 
in IETF so that it can used elsewhere. Provide comments before December. 
 From a technical point of view, all previous comments have been 
captured in the doc. If the draft is fine, please say that too.

-------------------------------------------
Wrap-up and Next (5 minutes)
--------------------
13:55 - 14:00 Next Steps: WG Chairs & ADs (5 minutes)
Presenter: Lionel
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-dime-0.pdf

slide 8: Milestones

Lionel - I need to write up the e2e security draft. Group signaling is 
blocked. Otherwise we're on track.

Steve - I don't see DRMP.

Lionel - Correct - mistake.

Steve - how to go forward with a security mechanism?

Lionel - Waiting for Jouni. You know about those Finnish guys. Everyone 
can propose a mechanism. I was waiting for a proposal form security 
area, but we can go forward.

Steve - it's not on the milestone list.

Lionel - it's in charter text, I'll add a milestone.

Lionel - do we need an interim meeting?  Can discuss on mailing list - 
end jan/feb.

Steve - If we have an interim meeting, need to add all outstanding 
drafts to it, but I'd be surprised if we need it. We just need reviews.

Lionel - On charter we're right on track. Maybe proposal of new app. If 
you think of one, propose to list. We have room to work on new topics. 
Any comments or topics?

No further comments or questions from working group.

ACTION: Lionel to update milestones with DRMP and security mechanism.

---

From: <[email-masked]>
Date: Wed, 11 Nov 2015 05:41:56 +0000

Thank you very much for your raw and summary notes.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de A. Jean Mahoney
Envoyé : jeudi 5 novembre 2015 02:11
À : [email-masked]
Objet : [Dime] dime 94 meeting notes - raw

Hi all,

Below are my raw notes from the meeting. Comments I missed are marked with ellipses (...) or ajm.

Thanks,

Jean

dime 94

1300-1400  TUESDAY, November 3, 2015, Afternoon Session I (60 mins) meeting room: Room 413 Jabber room: dime at jabber.ietf.org

slide 1: Title

slide 2: Note Well

slide 4: Agenda 1/2

slide 5: Agenda 2/2

draft-ietf-dime-ovli-10 - RFC 7683
draft-ietf-dime-4over6-provisioning - RFC 7678 draft-ietf-dime-congestion-flow-attributes - RFC 7660

Lionel - I've done the doc shepherd writeup. I think that some points need to be clarified/corrected. Jouni will take the discussion to list. 
May not need new WGLC, but will need a new version.

slide 1: Title

slide 2: Changes in -01

slide 5: Open Questions

No one had comments.

slide 6: Next Steps

slide 1: Title

slide 2: Changes in -01

slide 4: Load AVPs

slide 5: Next Steps

slide 1: Title

slide 2: Agenda

slide 3: Changes in -03

slide 4: Next Steps

slide 1: Title

slide 2: Status

slide 3: Open Question

slide 4: Next Steps

slide 8: Milestones

_______________________________________________
DiME mailing list
[email-masked]
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.