On Wed, Apr 30, 2014 at 7:13 AM, Joel Halpern Direct < [email protected]> wrote:
> There are at least two reasons why I at least find the reasonable quesiton > you have asked to be difficult to answer. > > First, it is not at all obvious that manipulation of the access control is > within scope for I2RS. The permissions may not even be defined and > manipulated on the same device where the I2RS agent resides. > > Agreed. Vendors and operators would prefer a single ACM that applies to all protocols. (Even though NACM says it is only for NETCONF, nobody implements it that way. CLI, WEBui, RESTCONF, etc. all use the same authorization rules. Second, we are working on an information model. RFC 6536 is a data model, > and specific to the NetConf/YANG data model. > > Most of it is YANG-specific, not NETCONF-specific. The access rules are based on YANG statements. But only the behavior for the NETCONF protocol is defined in detail. I doubt NACM could be used without additional text in some I2RS RFC. Personally, as I have said repeatedly, I do not see any reason for us to > have an information model for this until we conclude that there is some > manipulation of it which is within scope. > > Agreed. The info model and the data model are written (mostly) independent of access control. Yours, > Joel > Andy > > On 4/30/14, 10:02 AM, Andy Bierman wrote: > >> >> >> >> On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern <[email protected] >> <mailto:[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] >> <mailto:[email protected]>] >> Sent: Tuesday, April 29, 2014 10:20 AM >> To: Nitin Bahadur; Susan Hares; 'Mach Chen'; [email protected] >> <mailto:[email protected]> >> Cc: [email protected] >> <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/__listinfo/i2rs >> <https://www.ietf.org/mailman/listinfo/i2rs> >> >> >> >> _________________________________________________ >> i2rs mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/__listinfo/i2rs >> <https://www.ietf.org/mailman/listinfo/i2rs> >> >> >>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
