Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
- Original Message -
From: "Andy Bierman"
Sent: Thursday, January 10, 2019 5:45 PM
On Thu, Jan 10, 2019 at 4:42 AM Acee Lindem (acee) wrote:
> Hi Andy,
>
> On 1/10/19, 7:38 AM, "Andy Bierman" wrote:
>
> On Thu, Jan 10, 2019 at 12:34 AM wrote:
> > Hi Andy,
> >
> > What I’m still not catching is the difference you make between
> having a
> > description statement telling :” A server MUST accept a string
up to
> 64
> > characters in length” and a type string with length “0..64” ?
> >
> > There is probably something that I’m missing here.
>
> A server MAY accept a string longer than 64 characters.
> A range 0..64 means a server MUST NOT accept a string longer than
64
> Characters
>
> I don't think we should set the string range unless the range in
specified
> in the protocol RFCs. In some cases, it may be beneficial to provide
> guidance in the description. I believe this is similar to Juergen's
> position.
Agreed -- that is a good guideline for protocol related strings.
But what about admin strings?
NETCONF/YANG does not have a data type like SnmpAdminString
(which has a range of 0..255 octets)
Some of us implement servers using the theory that the NMS knows
what it's doing and servers do what they are told. So if the client
configured a 1M byte admin string the server would try to accept it
instead
of putting an arbitrary limit (because there is no YANG limit).
I prefer the SnmpAdminString approach because the client knows what
every compliant server will accept. But YANG models just use plain
string
and only regression test tools ask for 1M byte admin strings. IMO, this
has
not been
a problem in real deployments. We should continue to use plain "string"
for
admin strings.
Andy
Having spent decades working with SNMP, I am well familiar with, and
comfortable, with SnmpAdminString and it is doubtless this background
that lies behind some of my comments on strings. Juergen is right to
differentiate what would be a protocol failure, and so suitable for a
YANG range statement, from a nice-to-know, suitable for a YANG
'description'. But then I see discussions like the one I referred to on
the IDR WG list about how long to allow for an error message and think
that YANG is missing an adminstring type so I find myself commenting on
the YANG descripiton, wanting it to say more, and I find myself doing
this across several WG..
Tom Petch
Thanks,
> Acee
Andy
> > Brgds,
>
> Andy
> > *From:* Andy Bierman [mailto:a...@yumaworks.com]
> > *Sent:* Wednesday, January 09, 2019 18:06
> >
> > Hi,
> >
> > I agree with Juergen.
> >
> > The protocol has a "too-big" error is the server will not accept
a
> big
> > string.
> >
> > There should not be a false choice between an arbitrary maximum
and
> > "terabytes".
> >
> > You cannot use a range-stmt to specify the minimum required
length
> that
> > must be supported.
> >
> > length "3..max" does not allow strings of length 0 - 2.
> >
> > The description-stmt can have "A server MUST accept a string up
to 64
> > characters in length"
> >
> > which lets the client choose a length from 0 to 64, and this
will
> work on
> > all server implementations.
> >
> > Andy
> >
> >
> >
> >
> >
> > On Wed, Jan 9, 2019 at 5:10 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > Hi,
> >
> > please see my other email about the distinction I make between a
hard
> > length restriction and the minimum length expected to be
supported.
> I
> > wonder how you can sensibly pick a limit for things like
> non-best-reason:
> >
> > leaf non-best-reason {
> > type string;
> > description
> > "Information field to describe why the alternate
> > is not best.";
> > }
> >
> > You are simply creating an arbitrary restriction. And humble
server
> is
> > not likely to send you an jpg image (and a bogus server will do
so
> > anyway). (There are other similar objects.)
> >
> > Since I am searching for 'type string', I wonder whether these
are
> > clear enough definitions.
> >
> > leaf prefix {
> > type string;
> > description
> > "Protected prefix.";
> > }
> > leaf alternate {
> > type string;
> > description
> > "Alternate nexthop for the prefix.";
> > }
> >
> > What is the (canonical) format of the allowed values? (There are
> more of
> > these.)
> >
> > /js
> >
> > On Wed, Jan 09, 2019 at 12:52:07PM +,
> stephane.litkow...@orange.com
> > wrote:
> > > Hi Tom,
> > >
> > > If you agree, I will set a length restriction on each string
(ops
> and
> > cfg). It looks
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
On Thu, Jan 10, 2019 at 4:42 AM Acee Lindem (acee) wrote:
> Hi Andy,
>
> On 1/10/19, 7:38 AM, "Andy Bierman" wrote:
>
> On Thu, Jan 10, 2019 at 12:34 AM
> wrote:
>
> > Hi Andy,
> >
> >
> >
> > What I’m still not catching is the difference you make between
> having a
> > description statement telling :” A server MUST accept a string up to
> 64
> > characters in length” and a type string with length “0..64” ?
> >
> > There is probably something that I’m missing here.
> >
> >
> >
>
> A server MAY accept a string longer than 64 characters.
> A range 0..64 means a server MUST NOT accept a string longer than 64
> Characters
>
> I don't think we should set the string range unless the range in specified
> in the protocol RFCs. In some cases, it may be beneficial to provide
> guidance in the description. I believe this is similar to Juergen's
> position.
>
>
Agreed -- that is a good guideline for protocol related strings.
But what about admin strings?
NETCONF/YANG does not have a data type like SnmpAdminString
(which has a range of 0..255 octets)
Some of us implement servers using the theory that the NMS knows
what it's doing and servers do what they are told. So if the client
configured a 1M byte admin string the server would try to accept it instead
of putting an arbitrary limit (because there is no YANG limit).
I prefer the SnmpAdminString approach because the client knows what
every compliant server will accept. But YANG models just use plain string
and only regression test tools ask for 1M byte admin strings. IMO, this has
not been
a problem in real deployments. We should continue to use plain "string" for
admin strings.
Thanks,
> Acee
>
Andy
>
>
>
> > Brgds,
> >
> >
> >
>
>
> Andy
>
>
> > *From:* Andy Bierman [mailto:a...@yumaworks.com]
> > *Sent:* Wednesday, January 09, 2019 18:06
> > *To:* Juergen Schoenwaelder; LITKOWSKI Stephane OBS/OINIS; tom petch;
> > Ebben Aries; yang-doct...@ietf.org;
> > draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > *Subject:* Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> > draft-ietf-isis-yang-is-is-cfg-29
> >
> >
> >
> > Hi,
> >
> >
> >
> > I agree with Juergen.
> >
> > The protocol has a "too-big" error is the server will not accept a
> big
> > string.
> >
> > There should not be a false choice between an arbitrary maximum and
> > "terabytes".
> >
> >
> >
> > You cannot use a range-stmt to specify the minimum required length
> that
> > must be supported.
> >
> > length "3..max" does not allow strings of length 0 - 2.
> >
> >
> >
> > The description-stmt can have "A server MUST accept a string up to 64
> > characters in length"
> >
> > which lets the client choose a length from 0 to 64, and this will
> work on
> > all server implementations.
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> > On Wed, Jan 9, 2019 at 5:10 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > Hi,
> >
> > please see my other email about the distinction I make between a hard
> > length restriction and the minimum length expected to be supported.
> I
> > wonder how you can sensibly pick a limit for things like
> non-best-reason:
> >
> > leaf non-best-reason {
> > type string;
> > description
> > "Information field to describe why the alternate
> > is not best.";
> > }
> >
> > You are simply creating an arbitrary restriction. And humble server
> is
> > not likely to send you an jpg image (and a bogus server will do so
> > anyway). (There are other similar objects.)
> >
> > Since I am searching for 'type string', I wonder whether these are
> > clear enough definitions.
> >
> > leaf prefix {
> > type string;
> > description
> > "Protected prefix.";
> > }
> > leaf alternate {
> > type string;
> >
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Hi Andy,
On 1/10/19, 7:38 AM, "Andy Bierman" wrote:
On Thu, Jan 10, 2019 at 12:34 AM wrote:
> Hi Andy,
>
>
>
> What I’m still not catching is the difference you make between having a
> description statement telling :” A server MUST accept a string up to 64
> characters in length” and a type string with length “0..64” ?
>
> There is probably something that I’m missing here.
>
>
>
A server MAY accept a string longer than 64 characters.
A range 0..64 means a server MUST NOT accept a string longer than 64
Characters
I don't think we should set the string range unless the range in specified in
the protocol RFCs. In some cases, it may be beneficial to provide guidance in
the description. I believe this is similar to Juergen's position.
Thanks,
Acee
> Brgds,
>
>
>
Andy
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Wednesday, January 09, 2019 18:06
> *To:* Juergen Schoenwaelder; LITKOWSKI Stephane OBS/OINIS; tom petch;
> Ebben Aries; yang-doct...@ietf.org;
> draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> *Subject:* Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
>
>
>
> Hi,
>
>
>
> I agree with Juergen.
>
> The protocol has a "too-big" error is the server will not accept a big
> string.
>
> There should not be a false choice between an arbitrary maximum and
> "terabytes".
>
>
>
> You cannot use a range-stmt to specify the minimum required length that
> must be supported.
>
> length "3..max" does not allow strings of length 0 - 2.
>
>
>
> The description-stmt can have "A server MUST accept a string up to 64
> characters in length"
>
> which lets the client choose a length from 0 to 64, and this will work on
> all server implementations.
>
>
>
> Andy
>
>
>
>
>
> On Wed, Jan 9, 2019 at 5:10 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> Hi,
>
> please see my other email about the distinction I make between a hard
> length restriction and the minimum length expected to be supported. I
> wonder how you can sensibly pick a limit for things like non-best-reason:
>
> leaf non-best-reason {
> type string;
> description
> "Information field to describe why the alternate
> is not best.";
> }
>
> You are simply creating an arbitrary restriction. And humble server is
> not likely to send you an jpg image (and a bogus server will do so
> anyway). (There are other similar objects.)
>
> Since I am searching for 'type string', I wonder whether these are
> clear enough definitions.
>
> leaf prefix {
> type string;
> description
> "Protected prefix.";
> }
> leaf alternate {
> type string;
> description
> "Alternate nexthop for the prefix.";
> }
>
> What is the (canonical) format of the allowed values? (There are more of
> these.)
>
> /js
>
> On Wed, Jan 09, 2019 at 12:52:07PM +, stephane.litkow...@orange.com
> wrote:
> > Hi Tom,
> >
> > If you agree, I will set a length restriction on each string (ops and
> cfg). It looks clearer for me rather than setting it in the description.
> >
> > For the references, I'm working on it.
> >
> > Brgds,
> >
> >
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Wednesday, January 09, 2019 12:38
> > To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
> > Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > Subject: Re: [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
> >
> > Stephane
> >
> > Thanks for persisting.
> >
> > On string lengths, I take your point about no user input to Operational
> > State; there, my concern is more about giving guidance to implementors
> > as to what they should cater for - as I said, this has been a topic of
>
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
On Thu, Jan 10, 2019 at 12:34 AM wrote:
> Hi Andy,
>
>
>
> What I’m still not catching is the difference you make between having a
> description statement telling :” A server MUST accept a string up to 64
> characters in length” and a type string with length “0..64” ?
>
> There is probably something that I’m missing here.
>
>
>
A server MAY accept a string longer than 64 characters.
A range 0..64 means a server MUST NOT accept a string longer than 64
characters
> Brgds,
>
>
>
Andy
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Wednesday, January 09, 2019 18:06
> *To:* Juergen Schoenwaelder; LITKOWSKI Stephane OBS/OINIS; tom petch;
> Ebben Aries; yang-doct...@ietf.org;
> draft-ietf-isis-yang-isis-cfg....@ietf.org; lsr@ietf.org
> *Subject:* Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
>
>
>
> Hi,
>
>
>
> I agree with Juergen.
>
> The protocol has a "too-big" error is the server will not accept a big
> string.
>
> There should not be a false choice between an arbitrary maximum and
> "terabytes".
>
>
>
> You cannot use a range-stmt to specify the minimum required length that
> must be supported.
>
> length "3..max" does not allow strings of length 0 - 2.
>
>
>
> The description-stmt can have "A server MUST accept a string up to 64
> characters in length"
>
> which lets the client choose a length from 0 to 64, and this will work on
> all server implementations.
>
>
>
> Andy
>
>
>
>
>
> On Wed, Jan 9, 2019 at 5:10 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> Hi,
>
> please see my other email about the distinction I make between a hard
> length restriction and the minimum length expected to be supported. I
> wonder how you can sensibly pick a limit for things like non-best-reason:
>
> leaf non-best-reason {
> type string;
> description
> "Information field to describe why the alternate
> is not best.";
> }
>
> You are simply creating an arbitrary restriction. And humble server is
> not likely to send you an jpg image (and a bogus server will do so
> anyway). (There are other similar objects.)
>
> Since I am searching for 'type string', I wonder whether these are
> clear enough definitions.
>
> leaf prefix {
> type string;
> description
> "Protected prefix.";
> }
> leaf alternate {
> type string;
> description
> "Alternate nexthop for the prefix.";
> }
>
> What is the (canonical) format of the allowed values? (There are more of
> these.)
>
> /js
>
> On Wed, Jan 09, 2019 at 12:52:07PM +, stephane.litkow...@orange.com
> wrote:
> > Hi Tom,
> >
> > If you agree, I will set a length restriction on each string (ops and
> cfg). It looks clearer for me rather than setting it in the description.
> >
> > For the references, I'm working on it.
> >
> > Brgds,
> >
> >
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Wednesday, January 09, 2019 12:38
> > To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
> > Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > Subject: Re: [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
> >
> > Stephane
> >
> > Thanks for persisting.
> >
> > On string lengths, I take your point about no user input to Operational
> > State; there, my concern is more about giving guidance to implementors
> > as to what they should cater for - as I said, this has been a topic of
> > lively discussion in other WG. Even before that, whenever I see a
> > string, I think is there an implicit length restriction and if not,
> > should there be an explicit one which, as Juergen suggested, could be in
> > the description clause. My experience is that those working with
> > networks think about size, about length; those coming from applications
> > tend to think 'What is a few terabytes between friends?' and are unaware
> > that sizes that may be commonplace in servers and associated storage can
> > create difficulties over a network. Whatever, I leave this one up to
> > you.
> >
> > On references, I would like a change; you say this information is in the
> > base ISO spec. Well, yes, to me that means that it should be a
> > Normative Reference. I could not und
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
On Wed, Jan 09, 2019 at 05:59:08PM +, Acee Lindem (acee) wrote:
> leaf authentication-key {
> type string;
> description
> "Authentication keyto be used. For security reasons,
>the authentication key MUST NOT be presented in
>plaintext format. It is recommended to use an MD5
>hash to present the authentication-key.";
> }
> description
> "IS-IS node authentication information container -
> IS-IS reference is TLV 10.";
>
> Every implementor can make up his own identifier format and choose a
> format for the keys arbitrarily? Some do MD5 some SHA-1? Do we not
> have proper identifiers and formats defined already in some other YANG
> modules? You should look at RFC 7317, which did establish an IANA
> registry that you may find useful, perhaps also here (appears actually
> multiple times):
>
> No - User authentication and routing protocol transport authentication are 2
> very different things so RFC 7317 is not applicable. As you know the key
> length is dependent on the algorithm.
This does not resolve the issue that the format looks rather unclear,
means likely not interoperable. If routing people do not use common
crypt hash formats (see IANA registry), then you likely have to roll
your own equivalent.
> What are these hostname strings?
>
> leaf hostname {
> type string;
> description
> "Hostname associated with the system ID.";
> }
>
> An FQDN is recommended by not required - https://tools.ietf.org/html/rfc5301
The RFC 7317 definition does not require this either. It, however,
does rule out names like -+!23. Perhaps routers are happy with this.
(Well, do not most meanwhile run some Linux/BSD derivate? Well, up to
routing folks. It may, however, be helpful to explain how your
hostname relates to a system hostname or to spell out that it must be
expected to be different.)
/js
> Thanks,
> Acee
>
> Are these names following DNS conventions, similar to lets say this
> taken from RFC 7317:
>
> leaf hostname {
> type inet:domain-name;
>description
> "The name of the host. This name can be a single domain
> label or the fully qualified domain name of the host.";
> }
>
> /js
>
> On Wed, Jan 09, 2019 at 04:18:59PM +0100, Juergen Schoenwaelder wrote:
> > What is the value of your error leafs if there is no error to report
> > yet? Do you really want to rule out empty strings? Anyway, the semantics
> > are up to you to figure out.
> >
> > /js
> >
> > On Wed, Jan 09, 2019 at 02:55:40PM +, stephane.litkow...@orange.com
> wrote:
> > > Ok, so if we are silent about "must support at least", I think the
> only thing to do is to have 'type string "1.."' to avoid empty string as I
> don't see any requirement to have a minimum of x characters.
> > >
> > >
> > > -Original Message-
> > > From: Juergen Schoenwaelder
> [mailto:j.schoenwael...@jacobs-university.de]
> > > Sent: Wednesday, January 09, 2019 15:27
> > > To: LITKOWSKI Stephane OBS/OINIS
> > > Cc: tom petch; Ebben Aries; yang-doct...@ietf.org;
> draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > > Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
> > >
> > > Implementations must be robust and be able to deal with rogue input, a
> > > length restriction in the data model does not help solving that
> problem.
> > >
> > > Perhaps an example helps for the other question:
> > >
> > > leaf example {
> > > type string "3..";
> > > description
> > > "implementation must support a length of at least 42 characters"
> > > }
> > >
> > > Valid input can be any string which has at least three characters and
> > > implementations are expected to handle at least strings up to 42
> > > characters. An other alternative is to be silent about any
> > > expectations. A third option is to let server implementors document
> > > via deviations any length restrictions they may impose in their
> > > implementation.
> > >
> > > My preference is actually to
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Hi Juergen,
On 1/9/19, 12:14 PM, "Juergen Schoenwaelder"
wrote:
What is the relevance / lifetime of the error strings? When do error
leafs come into existence? How long do they stay? Can I distinguish
between a recent or an old error? I am just asking questions you
should have thought about.
Searching further for strings in draft-ietf-isis-yang-isis-cfg-29.txt,
I see this:
leaf authentication-type {
type string;
description
"Authentication type to be used with IS-IS node.";
}
We will discuss using an RFC 8177 type definition for this.
leaf authentication-key {
type string;
description
"Authentication keyto be used. For security reasons,
the authentication key MUST NOT be presented in
plaintext format. It is recommended to use an MD5
hash to present the authentication-key.";
}
description
"IS-IS node authentication information container -
IS-IS reference is TLV 10.";
Every implementor can make up his own identifier format and choose a
format for the keys arbitrarily? Some do MD5 some SHA-1? Do we not
have proper identifiers and formats defined already in some other YANG
modules? You should look at RFC 7317, which did establish an IANA
registry that you may find useful, perhaps also here (appears actually
multiple times):
No - User authentication and routing protocol transport authentication are 2
very different things so RFC 7317 is not applicable. As you know the key length
is dependent on the algorithm.
case password {
leaf key {
type string;
description
"This leaf specifies the authentication key.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Cryptographic algorithm associated with key.";
}
What are these hostname strings?
leaf hostname {
type string;
description
"Hostname associated with the system ID.";
}
An FQDN is recommended by not required - https://tools.ietf.org/html/rfc5301
Thanks,
Acee
Are these names following DNS conventions, similar to lets say this
taken from RFC 7317:
leaf hostname {
type inet:domain-name;
description
"The name of the host. This name can be a single domain
label or the fully qualified domain name of the host.";
}
/js
On Wed, Jan 09, 2019 at 04:18:59PM +0100, Juergen Schoenwaelder wrote:
> What is the value of your error leafs if there is no error to report
> yet? Do you really want to rule out empty strings? Anyway, the semantics
> are up to you to figure out.
>
> /js
>
> On Wed, Jan 09, 2019 at 02:55:40PM +, stephane.litkow...@orange.com
wrote:
> > Ok, so if we are silent about "must support at least", I think the only
thing to do is to have 'type string "1.."' to avoid empty string as I don't see
any requirement to have a minimum of x characters.
> >
> >
> > -Original Message-
> > From: Juergen Schoenwaelder
[mailto:j.schoenwael...@jacobs-university.de]
> > Sent: Wednesday, January 09, 2019 15:27
> > To: LITKOWSKI Stephane OBS/OINIS
> > Cc: tom petch; Ebben Aries; yang-doct...@ietf.org;
draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of
draft-ietf-isis-yang-is-is-cfg-29
> >
> > Implementations must be robust and be able to deal with rogue input, a
> > length restriction in the data model does not help solving that problem.
> >
> > Perhaps an example helps for the other question:
> >
> > leaf example {
> > type string "3..";
> > description
> > "implementation must support a length of at least 42 characters"
> > }
> >
> > Valid input can be any string which has at least three characters and
> > implementations are expected to handle at least strings up to 42
> > characters. An other alternative is to be silent about any
> > expectations. A third option is to let server implementors document
> > via deviations any length restrictions they may impose in their
> > implementation.
> >
> > My preference is actually to be silent abo
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
What is the relevance / lifetime of the error strings? When do error
leafs come into existence? How long do they stay? Can I distinguish
between a recent or an old error? I am just asking questions you
should have thought about.
Searching further for strings in draft-ietf-isis-yang-isis-cfg-29.txt,
I see this:
leaf authentication-type {
type string;
description
"Authentication type to be used with IS-IS node.";
}
leaf authentication-key {
type string;
description
"Authentication keyto be used. For security reasons,
the authentication key MUST NOT be presented in
plaintext format. It is recommended to use an MD5
hash to present the authentication-key.";
}
description
"IS-IS node authentication information container -
IS-IS reference is TLV 10.";
Every implementor can make up his own identifier format and choose a
format for the keys arbitrarily? Some do MD5 some SHA-1? Do we not
have proper identifiers and formats defined already in some other YANG
modules? You should look at RFC 7317, which did establish an IANA
registry that you may find useful, perhaps also here (appears actually
multiple times):
case password {
leaf key {
type string;
description
"This leaf specifies the authentication key.";
}
leaf crypto-algorithm {
type identityref {
base key-chain:crypto-algorithm;
}
description
"Cryptographic algorithm associated with key.";
}
What are these hostname strings?
leaf hostname {
type string;
description
"Hostname associated with the system ID.";
}
Are these names following DNS conventions, similar to lets say this
taken from RFC 7317:
leaf hostname {
type inet:domain-name;
description
"The name of the host. This name can be a single domain
label or the fully qualified domain name of the host.";
}
/js
On Wed, Jan 09, 2019 at 04:18:59PM +0100, Juergen Schoenwaelder wrote:
> What is the value of your error leafs if there is no error to report
> yet? Do you really want to rule out empty strings? Anyway, the semantics
> are up to you to figure out.
>
> /js
>
> On Wed, Jan 09, 2019 at 02:55:40PM +, stephane.litkow...@orange.com wrote:
> > Ok, so if we are silent about "must support at least", I think the only
> > thing to do is to have 'type string "1.."' to avoid empty string as I don't
> > see any requirement to have a minimum of x characters.
> >
> >
> > -Original Message-
> > From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> > Sent: Wednesday, January 09, 2019 15:27
> > To: LITKOWSKI Stephane OBS/OINIS
> > Cc: tom petch; Ebben Aries; yang-doct...@ietf.org;
> > draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> > draft-ietf-isis-yang-is-is-cfg-29
> >
> > Implementations must be robust and be able to deal with rogue input, a
> > length restriction in the data model does not help solving that problem.
> >
> > Perhaps an example helps for the other question:
> >
> > leaf example {
> > type string "3..";
> > description
> > "implementation must support a length of at least 42 characters"
> > }
> >
> > Valid input can be any string which has at least three characters and
> > implementations are expected to handle at least strings up to 42
> > characters. An other alternative is to be silent about any
> > expectations. A third option is to let server implementors document
> > via deviations any length restrictions they may impose in their
> > implementation.
> >
> > My preference is actually to be silent about "must support at least"
> > constrained unless there is a clear technical reason for a specific
> > number.
> >
> > /js
> >
> > On Wed, Jan 09, 2019 at 01:27:05PM +, stephane.litkow...@orange.com
> > wrote:
> > > Hi Juergen,
> > >
> > > There is something that I'm missing (sorry for that). How defining a
> > > minimum length helps to deal with rogue input ? I see a rogue input more
> > > being a too long string. Too short can happen if a specific leaf really
> > > requires a minimum length string, but I don't think that we have such a
> > > case.
> > > In addition, when your talk about minimum length in your email below, do
> > > I need t
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Hi,
I agree with Juergen.
The protocol has a "too-big" error is the server will not accept a big
string.
There should not be a false choice between an arbitrary maximum and
"terabytes".
You cannot use a range-stmt to specify the minimum required length that
must be supported.
length "3..max" does not allow strings of length 0 - 2.
The description-stmt can have "A server MUST accept a string up to 64
characters in length"
which lets the client choose a length from 0 to 64, and this will work on
all server implementations.
Andy
On Wed, Jan 9, 2019 at 5:10 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> Hi,
>
> please see my other email about the distinction I make between a hard
> length restriction and the minimum length expected to be supported. I
> wonder how you can sensibly pick a limit for things like non-best-reason:
>
> leaf non-best-reason {
> type string;
> description
> "Information field to describe why the alternate
> is not best.";
> }
>
> You are simply creating an arbitrary restriction. And humble server is
> not likely to send you an jpg image (and a bogus server will do so
> anyway). (There are other similar objects.)
>
> Since I am searching for 'type string', I wonder whether these are
> clear enough definitions.
>
> leaf prefix {
> type string;
> description
> "Protected prefix.";
> }
> leaf alternate {
> type string;
> description
> "Alternate nexthop for the prefix.";
> }
>
> What is the (canonical) format of the allowed values? (There are more of
> these.)
>
> /js
>
> On Wed, Jan 09, 2019 at 12:52:07PM +, stephane.litkow...@orange.com
> wrote:
> > Hi Tom,
> >
> > If you agree, I will set a length restriction on each string (ops and
> cfg). It looks clearer for me rather than setting it in the description.
> >
> > For the references, I'm working on it.
> >
> > Brgds,
> >
> >
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Wednesday, January 09, 2019 12:38
> > To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
> > Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > Subject: Re: [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
> >
> > Stephane
> >
> > Thanks for persisting.
> >
> > On string lengths, I take your point about no user input to Operational
> > State; there, my concern is more about giving guidance to implementors
> > as to what they should cater for - as I said, this has been a topic of
> > lively discussion in other WG. Even before that, whenever I see a
> > string, I think is there an implicit length restriction and if not,
> > should there be an explicit one which, as Juergen suggested, could be in
> > the description clause. My experience is that those working with
> > networks think about size, about length; those coming from applications
> > tend to think 'What is a few terabytes between friends?' and are unaware
> > that sizes that may be commonplace in servers and associated storage can
> > create difficulties over a network. Whatever, I leave this one up to
> > you.
> >
> > On references, I would like a change; you say this information is in the
> > base ISO spec. Well, yes, to me that means that it should be a
> > Normative Reference. I could not understand the description of e.g.
> > 'i/e' and needed to look it up but seemingly cannot do so with the
> > listed references of the I-D. Note that RFC such as RFC5305 and RFC6119
> > do reference International Standard 10589 and I think that this one
> > should too, perhaps in s.2.7 and s.5.
> >
> > Tom Petch
> >
> > - Original Message -
> > From:
> > Sent: Wednesday, January 09, 2019 9:18 AM
> >
> > Hi Tom,
> >
> > Please find inline answers.
> >
> >
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Tuesday, January 08, 2019 18:45
> >
> > Ok. Top-posting the ones that are not 'ok':
> >
> > I said that I thought that LSP did not need expanding on first use and
> > then checked the RFC Editor list to find that it is not one they regard
> > as well-known and that LSR protocols use it differently to others, so I
> > suggest expanding LSP on first use.
> >
> > [SLI] Already done for the next version.
> >
> > On lengths of text messages, perhaps I am too sensitive to buffer
> > overrun attacks and the like and so want a maximum on many things (and
> > then people attach a friendly, 20Mbyte photo to their e-mail at
> > Christmas and
> > wonder why their ESP rejects the message so I do not congratulate them
> > on the latest addition to the family:-). The IDR WG had a lively
> > discussion about maximum message lengths in 2017 and that has also
> > stayed in my mind. I have seen the comments on this by Juergen and
> > Lada; perhaps as Juergen intimates, something in the Description
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Ok, so if we are silent about "must support at least", I think the only thing
to do is to have 'type string "1.."' to avoid empty string as I don't see any
requirement to have a minimum of x characters.
-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Wednesday, January 09, 2019 15:27
To: LITKOWSKI Stephane OBS/OINIS
Cc: tom petch; Ebben Aries; yang-doct...@ietf.org;
draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of
draft-ietf-isis-yang-is-is-cfg-29
Implementations must be robust and be able to deal with rogue input, a
length restriction in the data model does not help solving that problem.
Perhaps an example helps for the other question:
leaf example {
type string "3..";
description
"implementation must support a length of at least 42 characters"
}
Valid input can be any string which has at least three characters and
implementations are expected to handle at least strings up to 42
characters. An other alternative is to be silent about any
expectations. A third option is to let server implementors document
via deviations any length restrictions they may impose in their
implementation.
My preference is actually to be silent about "must support at least"
constrained unless there is a clear technical reason for a specific
number.
/js
On Wed, Jan 09, 2019 at 01:27:05PM +, stephane.litkow...@orange.com wrote:
> Hi Juergen,
>
> There is something that I'm missing (sorry for that). How defining a minimum
> length helps to deal with rogue input ? I see a rogue input more being a too
> long string. Too short can happen if a specific leaf really requires a
> minimum length string, but I don't think that we have such a case.
> In addition, when your talk about minimum length in your email below, do I
> need to understand it as "minimum length to be supported by the
> implementation" ? (you said before: "'implementations should at least handle
> a length of x characters'"). This means that the user can input a string of
> any size between 0 and this minimum length to be supported. Or is it really a
> minimum length so the user cannot input something shorter than this value ?
>
> Brgds,
>
>
> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Wednesday, January 09, 2019 13:10
> To: tom petch
> Cc: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org;
> draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
>
> Hi,
>
> just to clarify: My position is that implementations have to be able
> to deal with rogue input no matter whether there is a length
> restriction defined in a data model or not. If people argue for length
> restrictions, then this should be done for interoperability reasons.
> And for this you may want to define a minimum length that must be
> supported instead of a maximum length that defines a hard upper
> boundary (and the only place to define such a minimum length and
> implementations must support so far is in the description statement).
>
> /js
>
> On Wed, Jan 09, 2019 at 11:37:45AM +, tom petch wrote:
> > Stephane
> >
> > Thanks for persisting.
> >
> > On string lengths, I take your point about no user input to Operational
> > State; there, my concern is more about giving guidance to implementors
> > as to what they should cater for - as I said, this has been a topic of
> > lively discussion in other WG. Even before that, whenever I see a
> > string, I think is there an implicit length restriction and if not,
> > should there be an explicit one which, as Juergen suggested, could be in
> > the description clause. My experience is that those working with
> > networks think about size, about length; those coming from applications
> > tend to think 'What is a few terabytes between friends?' and are unaware
> > that sizes that may be commonplace in servers and associated storage can
> > create difficulties over a network. Whatever, I leave this one up to
> > you.
> >
> > On references, I would like a change; you say this information is in the
> > base ISO spec. Well, yes, to me that means that it should be a
> > Normative Reference. I could not understand the description of e.g.
> > 'i/e' and needed to look it up but seemingly cannot do so with the
> > listed references of the I-D. Note that RFC such as RFC5305 and RFC6119
> > do reference International Standard 10589 and I think that this one
> > should too, perhap
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Implementations must be robust and be able to deal with rogue input, a
length restriction in the data model does not help solving that problem.
Perhaps an example helps for the other question:
leaf example {
type string "3..";
description
"implementation must support a length of at least 42 characters"
}
Valid input can be any string which has at least three characters and
implementations are expected to handle at least strings up to 42
characters. An other alternative is to be silent about any
expectations. A third option is to let server implementors document
via deviations any length restrictions they may impose in their
implementation.
My preference is actually to be silent about "must support at least"
constrained unless there is a clear technical reason for a specific
number.
/js
On Wed, Jan 09, 2019 at 01:27:05PM +, stephane.litkow...@orange.com wrote:
> Hi Juergen,
>
> There is something that I'm missing (sorry for that). How defining a minimum
> length helps to deal with rogue input ? I see a rogue input more being a too
> long string. Too short can happen if a specific leaf really requires a
> minimum length string, but I don't think that we have such a case.
> In addition, when your talk about minimum length in your email below, do I
> need to understand it as "minimum length to be supported by the
> implementation" ? (you said before: "'implementations should at least handle
> a length of x characters'"). This means that the user can input a string of
> any size between 0 and this minimum length to be supported. Or is it really a
> minimum length so the user cannot input something shorter than this value ?
>
> Brgds,
>
>
> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Wednesday, January 09, 2019 13:10
> To: tom petch
> Cc: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org;
> draft-ietf-isis-yang-isis-cfg....@ietf.org; lsr@ietf.org
> Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
>
> Hi,
>
> just to clarify: My position is that implementations have to be able
> to deal with rogue input no matter whether there is a length
> restriction defined in a data model or not. If people argue for length
> restrictions, then this should be done for interoperability reasons.
> And for this you may want to define a minimum length that must be
> supported instead of a maximum length that defines a hard upper
> boundary (and the only place to define such a minimum length and
> implementations must support so far is in the description statement).
>
> /js
>
> On Wed, Jan 09, 2019 at 11:37:45AM +, tom petch wrote:
> > Stephane
> >
> > Thanks for persisting.
> >
> > On string lengths, I take your point about no user input to Operational
> > State; there, my concern is more about giving guidance to implementors
> > as to what they should cater for - as I said, this has been a topic of
> > lively discussion in other WG. Even before that, whenever I see a
> > string, I think is there an implicit length restriction and if not,
> > should there be an explicit one which, as Juergen suggested, could be in
> > the description clause. My experience is that those working with
> > networks think about size, about length; those coming from applications
> > tend to think 'What is a few terabytes between friends?' and are unaware
> > that sizes that may be commonplace in servers and associated storage can
> > create difficulties over a network. Whatever, I leave this one up to
> > you.
> >
> > On references, I would like a change; you say this information is in the
> > base ISO spec. Well, yes, to me that means that it should be a
> > Normative Reference. I could not understand the description of e.g.
> > 'i/e' and needed to look it up but seemingly cannot do so with the
> > listed references of the I-D. Note that RFC such as RFC5305 and RFC6119
> > do reference International Standard 10589 and I think that this one
> > should too, perhaps in s.2.7 and s.5.
> >
> > Tom Petch
> >
> > - Original Message -
> > From:
> > Sent: Wednesday, January 09, 2019 9:18 AM
> >
> > Hi Tom,
> >
> > Please find inline answers.
> >
> >
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Tuesday, January 08, 2019 18:45
> >
> > Ok. Top-posting the ones that are not 'ok':
> >
> > I said that I thought that LSP did not need expanding on first use and
> > then checked the RFC
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Hi Juergen, There is something that I'm missing (sorry for that). How defining a minimum length helps to deal with rogue input ? I see a rogue input more being a too long string. Too short can happen if a specific leaf really requires a minimum length string, but I don't think that we have such a case. In addition, when your talk about minimum length in your email below, do I need to understand it as "minimum length to be supported by the implementation" ? (you said before: "'implementations should at least handle a length of x characters'"). This means that the user can input a string of any size between 0 and this minimum length to be supported. Or is it really a minimum length so the user cannot input something shorter than this value ? Brgds, -Original Message- From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] Sent: Wednesday, January 09, 2019 13:10 To: tom petch Cc: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org; draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org Subject: Re: [yang-doctors] [Lsr] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29 Hi, just to clarify: My position is that implementations have to be able to deal with rogue input no matter whether there is a length restriction defined in a data model or not. If people argue for length restrictions, then this should be done for interoperability reasons. And for this you may want to define a minimum length that must be supported instead of a maximum length that defines a hard upper boundary (and the only place to define such a minimum length and implementations must support so far is in the description statement). /js On Wed, Jan 09, 2019 at 11:37:45AM +, tom petch wrote: > Stephane > > Thanks for persisting. > > On string lengths, I take your point about no user input to Operational > State; there, my concern is more about giving guidance to implementors > as to what they should cater for - as I said, this has been a topic of > lively discussion in other WG. Even before that, whenever I see a > string, I think is there an implicit length restriction and if not, > should there be an explicit one which, as Juergen suggested, could be in > the description clause. My experience is that those working with > networks think about size, about length; those coming from applications > tend to think 'What is a few terabytes between friends?' and are unaware > that sizes that may be commonplace in servers and associated storage can > create difficulties over a network. Whatever, I leave this one up to > you. > > On references, I would like a change; you say this information is in the > base ISO spec. Well, yes, to me that means that it should be a > Normative Reference. I could not understand the description of e.g. > 'i/e' and needed to look it up but seemingly cannot do so with the > listed references of the I-D. Note that RFC such as RFC5305 and RFC6119 > do reference International Standard 10589 and I think that this one > should too, perhaps in s.2.7 and s.5. > > Tom Petch > > - Original Message - > From: > Sent: Wednesday, January 09, 2019 9:18 AM > > Hi Tom, > > Please find inline answers. > > > -Original Message- > From: tom petch [mailto:ie...@btconnect.com] > Sent: Tuesday, January 08, 2019 18:45 > > Ok. Top-posting the ones that are not 'ok': > > I said that I thought that LSP did not need expanding on first use and > then checked the RFC Editor list to find that it is not one they regard > as well-known and that LSR protocols use it differently to others, so I > suggest expanding LSP on first use. > > [SLI] Already done for the next version. > > On lengths of text messages, perhaps I am too sensitive to buffer > overrun attacks and the like and so want a maximum on many things (and > then people attach a friendly, 20Mbyte photo to their e-mail at > Christmas and > wonder why their ESP rejects the message so I do not congratulate them > on the latest addition to the family:-). The IDR WG had a lively > discussion about maximum message lengths in 2017 and that has also > stayed in my mind. I have seen the comments on this by Juergen and > Lada; perhaps as Juergen intimates, something in the Description would > help; and while the server may not be rogue, it may not have a perfect > implementation. > > [SLI] What I need to understand from your comment on string length > enforcement is if it applies to operational state or just config states > ? I do not see any issue of not enforcing the operational state as there > is no input from the user there and so no attack vector, this is purely > internal to the implementation. For config statements, it makes sense as > there is an input from th
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Hi,
please see my other email about the distinction I make between a hard
length restriction and the minimum length expected to be supported. I
wonder how you can sensibly pick a limit for things like non-best-reason:
leaf non-best-reason {
type string;
description
"Information field to describe why the alternate
is not best.";
}
You are simply creating an arbitrary restriction. And humble server is
not likely to send you an jpg image (and a bogus server will do so
anyway). (There are other similar objects.)
Since I am searching for 'type string', I wonder whether these are
clear enough definitions.
leaf prefix {
type string;
description
"Protected prefix.";
}
leaf alternate {
type string;
description
"Alternate nexthop for the prefix.";
}
What is the (canonical) format of the allowed values? (There are more of these.)
/js
On Wed, Jan 09, 2019 at 12:52:07PM +, stephane.litkow...@orange.com wrote:
> Hi Tom,
>
> If you agree, I will set a length restriction on each string (ops and cfg).
> It looks clearer for me rather than setting it in the description.
>
> For the references, I'm working on it.
>
> Brgds,
>
>
> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: Wednesday, January 09, 2019 12:38
> To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
> Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
>
> Stephane
>
> Thanks for persisting.
>
> On string lengths, I take your point about no user input to Operational
> State; there, my concern is more about giving guidance to implementors
> as to what they should cater for - as I said, this has been a topic of
> lively discussion in other WG. Even before that, whenever I see a
> string, I think is there an implicit length restriction and if not,
> should there be an explicit one which, as Juergen suggested, could be in
> the description clause. My experience is that those working with
> networks think about size, about length; those coming from applications
> tend to think 'What is a few terabytes between friends?' and are unaware
> that sizes that may be commonplace in servers and associated storage can
> create difficulties over a network. Whatever, I leave this one up to
> you.
>
> On references, I would like a change; you say this information is in the
> base ISO spec. Well, yes, to me that means that it should be a
> Normative Reference. I could not understand the description of e.g.
> 'i/e' and needed to look it up but seemingly cannot do so with the
> listed references of the I-D. Note that RFC such as RFC5305 and RFC6119
> do reference International Standard 10589 and I think that this one
> should too, perhaps in s.2.7 and s.5.
>
> Tom Petch
>
> - Original Message -
> From:
> Sent: Wednesday, January 09, 2019 9:18 AM
>
> Hi Tom,
>
> Please find inline answers.
>
>
> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: Tuesday, January 08, 2019 18:45
>
> Ok. Top-posting the ones that are not 'ok':
>
> I said that I thought that LSP did not need expanding on first use and
> then checked the RFC Editor list to find that it is not one they regard
> as well-known and that LSR protocols use it differently to others, so I
> suggest expanding LSP on first use.
>
> [SLI] Already done for the next version.
>
> On lengths of text messages, perhaps I am too sensitive to buffer
> overrun attacks and the like and so want a maximum on many things (and
> then people attach a friendly, 20Mbyte photo to their e-mail at
> Christmas and
> wonder why their ESP rejects the message so I do not congratulate them
> on the latest addition to the family:-). The IDR WG had a lively
> discussion about maximum message lengths in 2017 and that has also
> stayed in my mind. I have seen the comments on this by Juergen and
> Lada; perhaps as Juergen intimates, something in the Description would
> help; and while the server may not be rogue, it may not have a perfect
> implementation.
>
> [SLI] What I need to understand from your comment on string length
> enforcement is if it applies to operational state or just config states
> ? I do not see any issue of not enforcing the operational state as there
> is no input from the user there and so no attack vector, this is purely
> internal to the implementation. For config statements, it makes sense as
> there is an input from the user that can be anything.
>
>
> On the length of password, I saw a Security AD wanting clarification on
> this not too long ago so you may see this comment again from one such .
> Likewise, MD5 tends to be a red flag although I see it appears in bgp
> yang.
>
> I like the sort of detail in ippm-twamp-yang, on algorithms, entropy
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Hi,
just to clarify: My position is that implementations have to be able
to deal with rogue input no matter whether there is a length
restriction defined in a data model or not. If people argue for length
restrictions, then this should be done for interoperability reasons.
And for this you may want to define a minimum length that must be
supported instead of a maximum length that defines a hard upper
boundary (and the only place to define such a minimum length and
implementations must support so far is in the description statement).
/js
On Wed, Jan 09, 2019 at 11:37:45AM +, tom petch wrote:
> Stephane
>
> Thanks for persisting.
>
> On string lengths, I take your point about no user input to Operational
> State; there, my concern is more about giving guidance to implementors
> as to what they should cater for - as I said, this has been a topic of
> lively discussion in other WG. Even before that, whenever I see a
> string, I think is there an implicit length restriction and if not,
> should there be an explicit one which, as Juergen suggested, could be in
> the description clause. My experience is that those working with
> networks think about size, about length; those coming from applications
> tend to think 'What is a few terabytes between friends?' and are unaware
> that sizes that may be commonplace in servers and associated storage can
> create difficulties over a network. Whatever, I leave this one up to
> you.
>
> On references, I would like a change; you say this information is in the
> base ISO spec. Well, yes, to me that means that it should be a
> Normative Reference. I could not understand the description of e.g.
> 'i/e' and needed to look it up but seemingly cannot do so with the
> listed references of the I-D. Note that RFC such as RFC5305 and RFC6119
> do reference International Standard 10589 and I think that this one
> should too, perhaps in s.2.7 and s.5.
>
> Tom Petch
>
> - Original Message -
> From:
> Sent: Wednesday, January 09, 2019 9:18 AM
>
> Hi Tom,
>
> Please find inline answers.
>
>
> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: Tuesday, January 08, 2019 18:45
>
> Ok. Top-posting the ones that are not 'ok':
>
> I said that I thought that LSP did not need expanding on first use and
> then checked the RFC Editor list to find that it is not one they regard
> as well-known and that LSR protocols use it differently to others, so I
> suggest expanding LSP on first use.
>
> [SLI] Already done for the next version.
>
> On lengths of text messages, perhaps I am too sensitive to buffer
> overrun attacks and the like and so want a maximum on many things (and
> then people attach a friendly, 20Mbyte photo to their e-mail at
> Christmas and
> wonder why their ESP rejects the message so I do not congratulate them
> on the latest addition to the family:-). The IDR WG had a lively
> discussion about maximum message lengths in 2017 and that has also
> stayed in my mind. I have seen the comments on this by Juergen and
> Lada; perhaps as Juergen intimates, something in the Description would
> help; and while the server may not be rogue, it may not have a perfect
> implementation.
>
> [SLI] What I need to understand from your comment on string length
> enforcement is if it applies to operational state or just config states
> ? I do not see any issue of not enforcing the operational state as there
> is no input from the user there and so no attack vector, this is purely
> internal to the implementation. For config statements, it makes sense as
> there is an input from the user that can be anything.
>
>
> On the length of password, I saw a Security AD wanting clarification on
> this not too long ago so you may see this comment again from one such .
> Likewise, MD5 tends to be a red flag although I see it appears in bgp
> yang.
>
> I like the sort of detail in ippm-twamp-yang, on algorithms, entropy and
> such like (although I have not seen a review by Security AD/directorate
> of that).
>
> But I am left confused as to exactly what the cited object is doing.
> Yes, TLV10 provides authentication for any PDU, but what are the fields
> in the YANG module doing? Is
>leaf authentication-type {
> the first octet of TLV10? Is
> leaf authentication-key {
> the rest of TLV10? And where is this 'presented' as the YANG module
> says? Are you thinking of a YANG client presenting the field to a user
> at a terminal, one router presenting it to another, or what?
>
> I am using RFC5310 as my source for TLV10 and wondering why that is not
> a Normative Reference for this I-D
>
> [SLI] TLV 10 is defined in the base ISO spec of IS-IS. RFC5310 just adds
> the crypto auth as new types.
> The authentication-type is the first byte of the TLV (called
> Authentication Type as well).
> The authentication-key cannot be mapped directly to the
> authentication-value field. This is the case for ClearText password
> authtype but not
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Juergen Schoenwaelder writes:
> Defining and standardizing arbitrary limits is, well, arbitrary. What
> we often want, I think, is 'implementations should at least handle a
> length of x characters' but we have no way to say that in YANG today
> (other than description statements). Also note that # characters != #
IMO this is not a big issue here because the leaf in question is state
data. We have to assume that the client doesn't connect to a rogue
server, and that legitimate servers behave reasonably.
Lada
> bytes with UTF-8/Unicode character sets.
>
> /js
>
> On Mon, Jan 07, 2019 at 10:05:00AM +, stephane.litkow...@orange.com wrote:
>> Hi Tom,
>>
>> Regarding the length enforcement for operational state leaves that are using
>> string, do we need to always do it as a best practice ? There are plenty of
>> strings with no enforcement today like the "non-best-reason" that you have
>> pointed.
>>
>> Brgds,
>>
>>
>> -Original Message-
>> From: tom petch [mailto:ie...@btconnect.com]
>> Sent: Wednesday, January 02, 2019 12:17
>> To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
>> Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
>> Subject: Re: [Lsr] Yangdoctors last call review of
>> draft-ietf-isis-yang-is-is-cfg-29
>>
>> Here are the rest of my comments on -29 with a slight tweak to the
>> subject line. I would regard most of these (but not the first two) as
>> non-discussable, ie I won't complain if you disagree:-)
>>
>> RFC1195 is in the YANG module but not the references of the I-D
>>
>> RFC5029 is in the YANG module but not the references of the I-D
>>
>> PSNPs, CSNPs
>> expand on first use - LSP I think ok
>>
>> leaf best { type boolean;
>> what is true and what false? I can guess from the English semantics of
>> the name but would rather not guess.
>>
>> leaf non-best-reason { type string;
>> suggest a maximum length, perhaps 127 or 255 ( unless you expect
>> screenshots or packet traces to be attached). As it stands, you could
>> validly receive
>> a length of 18446744073709551615.
>>
>> You have a mixture of
>> System-id system-id System id System ID System Id system id system ID
>> suggest consistency; system-id wfm
>>
>> You have a mixture of
>> lsp-id LSPID LSP ID
>> here, perhaps lsp-id for the names and LSP ID in the text
>>
>> case password {leaf key { type string;
>> perhaps better with a minimum length
>>
>> leaf i-e { type boolean;
>> what is true and what false? here I am reluctant even to guess
>>
>> /"Authentication keyto/ "Authentication key to/
>>
>> " the authentication key MUST NOT be presented in"
>> RFC2119 language means that RFC2119 boilerplate should be in the YANG
>> module (but without the [..] ie the reference must be plain text not an
>> anchor).
>>
>>
>> It is recommended to use an MD5
>>hash to present the authentication-key.";
>> Mmm I think that this may be a red flag to security AD or directorate as
>> being too vague as well as MD5 too weak; and I think this should be
>> explicitly called out in Security Considerations.
>>
>> list level-db {key level;leaf level {
>> A common convention is for a list of leaf thing to be named things i.e.
>> list levels { key level;leaf level {
>>
>> rpc clear-adjacency {
>> "Name of the IS-IS protocol instance whose IS-IS
>>information is being queried.
>> queried or cleared?
>>
>> Tom Petch
>>
>>
>> - Original Message -
>> From: "tom petch"
>> Sent: Monday, December 31, 2018 6:21 PM
>> Subject: Re: [Lsr] Yangdoctors last call review of
>> draft-ietf-isis-yang-isis-cfg-24
>>
>>
>> > Stephane
>> >
>> > A new and different comment.
>> >
>> > grouping neighbor-gmpls-extensions {
>> >
>> > has a text reference to RFC5307 which does not appear in the
>> references
>> > for the I-D. However, before adding it, I would like to know why it
>> is
>> > a good reference for switching capabilities (which is part of this
>> > grouping). I think that the reference for switching capabilities
>> should
>> > be RFC7074 (which this I-D does not currently reference and should
>> IMO).
>> >
>> > And that begs the question, why is switching-capability an
>> unrestricted
>> > uint8 when only 12 values are valid and three are deprecated?
>> >
>> > So why not use
>> >
>> > draft-ietf-teas-yang-te-types?
>> >
>> > I have a number of additional comments on cfg-29 but this is the one
>> > that may take some discussion.
>> >
>> > Tom Petch
>> >
>> >
>> > - Original Message -
>> > From:
>> >
>> > Hi Tom,
>> >
>> > Thanks for your comments. I will fix them asap.
>> > Regarding:
>> > " Line length is within the RFC limit but the effect is to spread many
>> > of the description clauses over multiple lines with indentation of 56
>> > characters, not user friendly e.g.
>> >
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Defining and standardizing arbitrary limits is, well, arbitrary. What
we often want, I think, is 'implementations should at least handle a
length of x characters' but we have no way to say that in YANG today
(other than description statements). Also note that # characters != #
bytes with UTF-8/Unicode character sets.
/js
On Mon, Jan 07, 2019 at 10:05:00AM +, stephane.litkow...@orange.com wrote:
> Hi Tom,
>
> Regarding the length enforcement for operational state leaves that are using
> string, do we need to always do it as a best practice ? There are plenty of
> strings with no enforcement today like the "non-best-reason" that you have
> pointed.
>
> Brgds,
>
>
> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: Wednesday, January 02, 2019 12:17
> To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
> Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
>
> Here are the rest of my comments on -29 with a slight tweak to the
> subject line. I would regard most of these (but not the first two) as
> non-discussable, ie I won't complain if you disagree:-)
>
> RFC1195 is in the YANG module but not the references of the I-D
>
> RFC5029 is in the YANG module but not the references of the I-D
>
> PSNPs, CSNPs
> expand on first use - LSP I think ok
>
> leaf best { type boolean;
> what is true and what false? I can guess from the English semantics of
> the name but would rather not guess.
>
> leaf non-best-reason { type string;
> suggest a maximum length, perhaps 127 or 255 ( unless you expect
> screenshots or packet traces to be attached). As it stands, you could
> validly receive
> a length of 18446744073709551615.
>
> You have a mixture of
> System-id system-id System id System ID System Id system id system ID
> suggest consistency; system-id wfm
>
> You have a mixture of
> lsp-id LSPID LSP ID
> here, perhaps lsp-id for the names and LSP ID in the text
>
> case password {leaf key { type string;
> perhaps better with a minimum length
>
> leaf i-e { type boolean;
> what is true and what false? here I am reluctant even to guess
>
> /"Authentication keyto/ "Authentication key to/
>
> " the authentication key MUST NOT be presented in"
> RFC2119 language means that RFC2119 boilerplate should be in the YANG
> module (but without the [..] ie the reference must be plain text not an
> anchor).
>
>
> It is recommended to use an MD5
>hash to present the authentication-key.";
> Mmm I think that this may be a red flag to security AD or directorate as
> being too vague as well as MD5 too weak; and I think this should be
> explicitly called out in Security Considerations.
>
> list level-db {key level;leaf level {
> A common convention is for a list of leaf thing to be named things i.e.
> list levels { key level;leaf level {
>
> rpc clear-adjacency {
> "Name of the IS-IS protocol instance whose IS-IS
>information is being queried.
> queried or cleared?
>
> Tom Petch
>
>
> - Original Message -
> From: "tom petch"
> Sent: Monday, December 31, 2018 6:21 PM
> Subject: Re: [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-isis-cfg-24
>
>
> > Stephane
> >
> > A new and different comment.
> >
> > grouping neighbor-gmpls-extensions {
> >
> > has a text reference to RFC5307 which does not appear in the
> references
> > for the I-D. However, before adding it, I would like to know why it
> is
> > a good reference for switching capabilities (which is part of this
> > grouping). I think that the reference for switching capabilities
> should
> > be RFC7074 (which this I-D does not currently reference and should
> IMO).
> >
> > And that begs the question, why is switching-capability an
> unrestricted
> > uint8 when only 12 values are valid and three are deprecated?
> >
> > So why not use
> >
> > draft-ietf-teas-yang-te-types?
> >
> > I have a number of additional comments on cfg-29 but this is the one
> > that may take some discussion.
> >
> > Tom Petch
> >
> >
> > - Original Message -
> > From:
> >
> > Hi Tom,
> >
> > Thanks for your comments. I will fix them asap.
> > Regarding:
> > " Line length is within the RFC limit but the effect is to spread many
> > of the description clauses over multiple lines with indentation of 56
> > characters, not user friendly e.g.
> > description
> > "List of max LSP
> > bandwidths for different
> > priorities.";
> > "
> > What's your suggestion on this one ?
> >
> > Brgds,
> >
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Tuesday, November 27, 2018 12:11
> >
