Skip to main content

Diameter Load Information Conveyance
draft-ietf-dime-load-09

Yes

(Spencer Dawkins)
(Stephen Farrell)

No Objection

(Alexey Melnikov)
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Suresh Krishnan)

Recuse

(Ben Campbell)

Note: This ballot was opened for revision 07 and is now closed.

Spencer Dawkins Former IESG member
Yes
Yes (for -08) Unknown

                            
Stephen Farrell Former IESG member
Yes
Yes (for -07) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2017-03-15 for -08) Unknown
- From the shepherd writeup:
    The document would benefit from a review by AAA Doctors.

I wonder if it happened?

-
OLD:

   The DIME working group explicitly chose not to fulfill these
   requirements in DOIC due to several reasons. 

NEW:

   The DIME working group explicitly chose not to fulfill these
   requirements when publishing DOIC [RFC7683] due to several reasons. 

- pay attention to the consistency of Load versus load trough out the document.
Deborah Brungard Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2017-03-13 for -08) Unknown
consider reviewing the opsdir reviewers nits.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-03-15 for -08) Unknown
Since DIME doesn't have end-to-end security, shouldn't the security considerations section mention that as well?  It seems to fit the security considerations and would serve as a reminder of this problem.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-03-15 for -08) Unknown
More or less editorial comments:

1) These two MUSTs are actually hard to "ensure" and should probably be SHOULDs or lower case musts:
sec 6.1.1: "A Diameter endpoint that supports the Diameter Load mechanism MUST
   include a Load report of type HOST in sufficient answer messages to
   ensure that all consumers of the load information receive timely
   updates."
sec 6.1.2: "A Diameter Agent that supports the Diameter Load mechanism MUST
   include a PEER Load report in sufficient answer messages to ensure
   that all users of the load information receive timely updates."

2) This part also seems hard to realize (in sections 6.1.1. and 6.1.2):
"The LOAD value should be calculated in a way that reflects the
   available load independently of the weight of each server, in order
   to accurately compare LOAD values from different nodes.  Any specific
   LOAD value needs to identify the same amount of available capacity,
   regardless the Diameter node that calculates the value.

   The mechanism used to calculate the LOAD value that fulfills this
   requirement is an implementation decision."

3) I don't think you can require this for all diameter nodes (as they might not implement this extension):
"A Diameter node MUST be prepared to process Load reports of type HOST
   and of type PEER"
   Just remove the sentence or at least don't use normative language.
Side note: This MUST as well as the ones above are like saying "A node that implements/complies to this spec MUST implement this spec". It not really necessary to say this.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Ben Campbell Former IESG member
Recuse
Recuse (for -08) Unknown