On Apr 30, 2014:10:02 AM, at 10:02 AM, Andy Bierman <[email protected]> wrote:
> > > > 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? It was very much my understanding/intention to use RFC6536. --Tom > > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
