An open discussion list for topics related to the eduGAIN interfederation service.

[Nick Roy <nroy AT internet2.edu>]

Hi Tomasz, do you mind if I share this with the InCommon Technical 
Advisory Committee for their thoughts?

Thank you,

Nick

On 9/14/16 10:03 AM, Tomasz Wolniewicz wrote:
> Hi All,
>     Here I am, reopening this thread. Sorry for the length of what follows.
>
> A quick summary first.
> The current "hard" approach to eduGAIN aggregation is that if we spot a
> validation error then we mark the entire feed as broken and reject it.
> There have been voices in this thread pointing out that rejecting an
> entire feed of hundreds of entities because of a single offending entity
> is much too harsh and that perhaps eduGAIN MDS should filter out
> individual entities instead. This mail is primarily addressed to
> supporters of this "soft" approach.
>
> I am a strong advocate of the "hard" approach so I will put together my
> views why this is good and "soft" is bad, I am sure there will be
> opposite opinions as well. I will not hide that my true intention is to
> convince the SG to the decision supporting the "hard" solution and have
> this subject closed for at least a year.
>
> Pros for "hard".
>
> a) eduGAIN metadata profiles specifies the requirements for a correct
> feed and does not have a notion of a semi-correct one. Accepting
> something which is not correct and making decisions on what can be fixed
> and how should not be something for the central aggregator to do.
>
> b) This approach is clear and not open to any interpretations.
>
> c) The "hard" approach does not do any real harm - if we stick to the
> rule that ValidUntil should not ever drop below 4 days, the federation
> should have plenty of time to fix the feed before the cached copy might
> be dropped.
>
> d) This approach is very easy to implement, but perhaps this should not
> be a deciding factor.
>
> Cons against "soft". These really are the questions that automatically
> pop up, for which we will need to invent answers (read - new regulations).
>
> a) If we decide that a single entity can be dropped, what do we do if
> there are 2, 3, 100? Where is the limit?
>
> b) How long do we tolerate errors in a feed, should there be a time
> limit or do we just let it run indefinitely? If we set the limit, will
> the situation be that much different from having this time limit being
> equal to 0 which is another formulation of the "hard" approach.
> Eventually the limit will arrive and then what - drop the whole feed on
> the floor and leave nothing?
>
> c) If a federation feed suddenly has corrupt data about an entity that
> previously was OK what do we do? Keep the correct copy of this entity in
> metadata or simply drop it? We definitely cannot keep the entity longer
> than the validUntil of the last correct metadata feed, therefore to keep
> we would have to implement per-entity valid-until counters and separate
> per-entity warnings. This makes the system quite complex.
>
> d) The "soft" solution supports a lax approach to the way that
> federation cooperate within eduGAIN and we should not encourage that.
>
> Cheers
> Tomasz