Folks, There’s some ambiguity in the discussion here, from my perspective:
Option A: single ‘tag’ type which can represent a protocol tag, or some ‘colour’ attribute. Option B: multiple ‘tag’ types, a generic ‘colour’ and then per-protocol tags. Right now, oc-policy uses option A. I can see arguments for either - but Stephane I was not clear from your view which of these you prefer - can you clarify for me please? Thanks, r. On 20 July 2015 at 15:30:56, [email protected] ([email protected](mailto:[email protected])) wrote: > > Inline > > > > > > From: Jeffrey Haas [mailto:[email protected]] > Sent: Monday, July 20, 2015 16:05 > To: LITKOWSKI Stephane SCE/IBNF > Cc: [email protected] > Subject: Re: Comments on draft-shaikh-rtgwg-policy-model > > > > > > > > > > > > > On Jul 20, 2015, at 3:58 PM, > > [email protected](mailto:[email protected]) wrote: > > > > > > > > > > > > > > Right, each protocol has its own constraint, but do you think creating an > > additional generic marker will solve those constraints ? We would expect to > > be able to have the generic marker to protocol tag and also two protocol > > tags with different constraints to interact between each other (I mean for > > example, learning a RIP tag and copying it to ISIS or OSPF). > > > > > > > > > > > My thought is that by not using an element that has protocol semantics, we > can free the user from worrying about them when they don't care about whether > the route will or will not get redistributed into a protocol that might use > it. This is mostly to deal with your "local" property noted earlier. > > > > > > > [SLI] Agree, that’s why I was pushing “tag” to be protocol agnostic and > having only this tag and then let implementations to manage the translation > to protocol tag when necessary. > > > > > > > > > > > > > > > > > > -- Jeff > > > > > > > > _________________________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. If you have received this > email in error, please notify the sender and delete this message and its > attachments. As emails may be altered, Orange is not liable for messages that > have been modified, changed or falsified. Thank you. > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
