On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern <[email protected]>wrote:
> I do not think that matches the definition of role we are using. > An identity has a role. Several identities may have the same role. > And a role is defined by a collections if <im-tree-portion, access > permission> pairs. > > This is not specific to the RIB model, and should not be in the rib model > at all as far as I can tell. > > Separate from the definition of role, and again applicable across all > information models, an agent may itself have access restrictions. A client > using an agent is restricted to the access set which is permitted both by > its role and by what the agent has permission to do. > > Again, if we want to model that, we should model it outside of any > specific IM. > > NETCONF and RESTCONF already have a standard Role-Based Access Control Model, called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, leave it to vendors, or something else? > Yours, > Joel > Andy > > On 4/30/14, 7:26 AM, Susan Hares wrote: > >> Joel: >> >> Great! This is the answer I hoped to get. Just to make sure, We are >> defining a role as: identity + rib tree + access (read or write or >> read-write). >> If I define a tree portion that is read-only does that align with our role >> definitions. >> >> If this is a common definition, then I'm good to release the next version >> of >> the draft with read/write for the RIB-info. >> >> Sue >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:[email protected]] >> Sent: Tuesday, April 29, 2014 10:20 AM >> To: Nitin Bahadur; Susan Hares; 'Mach Chen'; [email protected] >> Cc: [email protected] >> Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 >> >> Remember that an information model is not a grammar. It is perfectly okay >> in an IM to have two branches that are just different things. >> Discriminators are added in when one goes from teh information model to >> the >> data model. >> >> Yours, >> Joel >> >> On 4/29/14, 2:36 AM, Nitin Bahadur wrote: >> >>> Hi Sue, >>> >>> >>>> >>>> >>>> 4) Would a corrections to the above be useful: >>>>> Given the above you could simplify your match RBNF: >>>>> >>>>> <match>:: = <route-tag> <rt-form> [ipv4-route | ipv6-route | >>>>> mpls-route >>>>> | mac-route] >>>>> >>>> >>>> [Nitin] The <rt-form> is not needed for mpls and mac routesŠ.since >>>> MPLS has no concept of SRC or DEST. So that simplification will >>>> actually not help :( >>>> >>>> [Sue]: Yes, not all forms would benefit. However, MPLS does have the >>>> stack tags that we may want to save and match on. Also: the 5-tuples >>>> may be a part of matching some routes. By using rt-form, we are >>>> using the TLV format to set-up these multiple formats. Each format, >>>> would have the appropriate expectations for the appropriate address >>>> families. >>>> >>>> [Sue]: I think it provides table based code. >>>> >>> >>> The main issue is that the grammar will not be deterministic. In other >>> words, one needs a way to specify that <route-tag-1> <rt-form-A> is >>> valid and <route-tag-1> <rt-form-B> is NOT valid. >>> >>> >>> >>>> The <ip-route-type> will need to be associated specifically with >>>> <ipv4-route> and <ipv6-route>. >>>> >>>> [Sue]: yes, it could. With the rt-form and the rib-family type, >>>> perhaps we can remove the rt-type. >>>> [snip] >>>> >>> >>> Rib-family-type and route-type are kind of the same thing. I need to >>> think if there is a case where they can be different... >>> >>> >>> >>>> 5) Why did you specify differently? >>>>> >>>>> multicast-source-ipv4-address ::=<IPv4-Address> <IPV4_PREFIX_LENGTH> >>>>> multicast-source-ipv6-address ::=<IPv6-Address><IPV6_PREFIX_LENGTH> >>>>> >>>>> Where you trying to express some checking that the node should have >>>>> on these address? >>>>> >>>> >>>> Thanks for catching this. They have no reference in the -02 version. >>>> They are a remnant of -00 of the draft. After the grammar was >>>> modified in -01, they should have been deleted. >>>> >>>> Here's the next question - how were you planning to handle the >>>> multiple next-hops for the multicast. Did you have a plan? >>>> >>>> You will have both ECMP (unicast) multiple nexthops, >>>> >>> >>> Unicast multiple next hops are covered in Section 7.2.3. >>> >>> >>> and multicast replication next hops. >>>> >>> >>> Section 7.3 talks about multicast replication (and refers to Section >>> 7.2.2). >>> >>> >>> A flag might do nicely to differentiate. >>>> We could put this on the next hop. >>>> >>> >>> LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to >>> indicate ECMP/load-balancing. >>> >>> >>> >>> Thanks >>> Nitin >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> >> > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
