Adrian,
As a further clarification on one point...
...
>
> ----------------------------------------------------------------------
> > After "However:" in section 3.2, I would suggest some form of
> > modification or qualification of the first bullet similar to:
> >
> > - A domain border node MUST NOT passively suppress propagation
> > of a PathErr message.
> >
> > Clearly, if the device applies a successful crankback approach,
> > it does not make sense for it to propagate the PathErr anyway.
>
> OK. This was obviously not sufficiently clear.
> It was meant to imply that the PathErr must
> - either be propagated
> - or dropped because some other action has been applied
> In other words, a PathErr must not simply be dropped
> according to policy,
> whim, or misadventure.
> (Actually, misadventure can occur because of the nature of IP :-)
>
> We can try to expan the text to make "passively suppress" less opaque.
Just to be clear, "passively" was what I added in the suggested
example of how to "fix" the problem.
>From what you say, it is not the intention that the domain border
LSR should be allowed to drop the PathErr without taking some sort
of action - hence my suggestion to add "passively". However, that
doesn't seem to clear it up enough.
I felt that the statement does not need too much improvement since
the example of holding the PathErr while the boundary LSR tries an
alternative (or two) follows very shortly after the statement. So,
I was suggesting adding a weak qualifier to keep from implying that
the PathErr MUST be forwarded under all circumstances - only to
follow shortly with an example of when it might make sense to not
do so.
If the example clearly said that - on subsequently succeeding - the
initial PathErr would (clearly) not need to be propagated, then I
would have ignored the previous statement (even though still a bit
inconsistent).
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
