On Thu, Feb 11, 2016 at 12:22:19PM +0000, William Lupton wrote:
> All,
>
> Here in the Broadband Forum we are defining YANG modules that augment RFC
> 7223 ietf-interfaces. We want to limit interface name maximum length and
> character set but don't see a way of doing this in the YANG.
>
> Can/should we do do this in the YANG, or should it just be a device-level
> requirement?
>
I wonder why you want to do this. Is it because other existing BBF
specifications break if interfaces can have long names and use Unicode
characters? Out of curiosity, what would be the length and character
set restriction BBF finds a good choice?
A deviation statement describes how an implementation deviates from a
data model. It was not the intent that an SDO defines a 'standard'
deviation for a data model (the term 'profile' might be more
appropriate for this).
Note that these kind of 'profiles' often do not combine well. If BBF
says the max length is N and MEF says that max length is N with N !=
M, then an implementor has a hard time to produce a device that
satisfies both requirements. (All one can do is to use min(N,M) and
then annouce a deviation to the profiles affected, all getting pretty
ugly soon, in particular if the common native interface names may be
longer than N and M.)
I understand that 'arbitrarily long' may sound ridiculous. But having
an implementation announce its real limit instead of a data model or
'profile' imposed limit seems simpler and more robust to me.
/js
PS: On Windows, MAX_ADAPTER_NAME_LENGTH seems to be 256, on Linux
IF_NAMESIZE seems to be 16, on FreeBSD and MacOS IF_NAMESIZE seems
to be 16 as well (but there are likely systems derived from
FreeBSD that use a different constant, may also be true for Linux
- and most likely people change this constant for a reason).
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
