Aijun,
> Each ORF type can have its own specific part, then the encoding of > “Sequence” doesn’t violate the specifications of RFC 5291. You can see > https://www.rfc-editor.org/rfc/rfc5292.html#section-3 has also the > “Sequence” number. > We have already established that subject specification does not have a valid use case for PERMIT (except this implicit PERMIT ALL as last entry which can be mandated by the spec. With that I do not see a valid justification to introduce the notion of sequence numbers to your DENY entries. That does more harm than good. First implementations which receive such ORF entries are not free to optimally choose how the ORF entries are applied and efficiently executed in their code basis. Second sender side needs to keep such sequence numbers per peer. You are not even using it _alone_ to REMOVE specified before DENY entries. And only copying it here because RFC5292 has it seems like a very weak justification. You are not comparing apples to apples. If you want to keep a unique ID per each rule sent - fine rename the Sequence ID to ID. Sequence IDs are very useful where you have both PERMIT and DENY rules interleaved ... here you clearly do not have such use cases. Thx, R.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
