On Mon, Dec 19, 2022 at 5:15 AM Martin Björklund <[email protected]> wrote:
> tom petch <[email protected]> wrote: > > From: Martin Björklund <[email protected]> > > Sent: 19 December 2022 12:18 > > To: tom petch > > > > tom petch <[email protected]> wrote: > > > draft-ietf-opsawg-sap-12 > > > defines a grouping sap-list which uses grouping sap-entry. The > groupings are intended for import by service specific modules. The uses > does not include a prefix; should it? > > > > From a YANG perspective this is correct. Since it references a > > grouping in the local module, the prefix is optional. > > > > <tp> > > But it will not be the local module when it is used in other modules > which is the only reason it is a grou[ing > > It doesn't matter how sap-list is used; it is well-defined in the > module ietf-sap-ntw. See section 5.4 in RFC 7950. > > > /martin > > > > > > module ietf-sap-vpn > > prefix sap-vpn > > import ietf-sap-ntw > > prefix sap > > container sap-l2vpn > > > > list l2vpn-service > > uses sap:sap-list > > ..... > > > > Does it need to know where to find sap-entry which sap-list 'uses' > without a prefix? > > > > Tom Petch > > > > > The module also has my favourite YANG construct, an unrestricted > string as a YANG key. > > > > I don't think that this is a problem. Or rather, if the theory is > > that we need to have restricted length on strings b/c otherwise an > > implementation may run out memory, then I don't think this solves that > > problem. But perhaps there is some other reason? > > There is an argument to be made that it is better to pick a reasonable length and a reasonable character set for an administrative string (going back to SnmpAdminString) That way, every implementation MUST support the same set of strings (modulo resource errors). I have the same reaction as Tom when I see 'string' as a key. Really? The server accepts zero-length identifiers, all-whitespace identifiers, and much worse... Probably not. > > > > /martin > Andy > > > > > > > > Copying Martin as he performed a YANG Doctor review earlier in 2022. > > > > > > Tom Petch > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
