> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > >> On 2018-12-06 01:16, Joe Touch wrote: >> >> >> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: >> >>>> Nobody deprecated the flags that require HBH options to be processed or dropped if not supported. >>> >>> Intentionally. If a forwarding node is transparent to HbH options, >>> it is not looking at those flags. If it is looking at HbH options, >>> it will obey those flags. Why is that a problem? >> >> What exactly does ‘transparent to HbH options mean’ if not ‘not supported’? > > It means a forwarding node that uses the exception added by RFC7045 and simply > doesn't even look for an HbH header. The flag bits are invisible and irrelevant > to such a node. The flag bits apply as defined for a forwarding node that *does* > process HbH options, so they certainly should not be deprecated Do why bother with “drop if not supported” if not supported can mean silently skipped over? Or the other variants? They’re now meaningless but required to support. You don’t see the contradiction? > > Brian > >> >> In that case, the flags have exactly no meaning anywhere. But they’re not deprecated. >> >> That makes no sense at all. >> >> Joe >> . >> >
