Re: [netmod] x509c2n:cert-to-name problem

[Randy Presuhn]

Hi -

On 10/28/2019 2:22 AM, Martin Bjorklund wrote:


No, in many SMIv2 objects, a zero-length value is used for optional
nodes (due to the way the protocol (SNMP) works).


This comes as a complete surprise to me.  References?

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-ietf-netmod-factory-default-04.txt

[Qin Wu]

发件人: Kent Watsen [mailto:kent+i...@watsen.net]
发送时间: 2019年10月28日 23:55
收件人: Joe Clarke (jclarke) 
抄送: Qin Wu ; netmod@ietf.org
主题: Re: [netmod] New Version Notification for 
draft-ietf-netmod-factory-default-04.txt


Regarding this point:

First, I remember we talked about a reboot operation I think at the last 
IETF(?).  It was said that perhaps a reboot would happen as part of this RPC 
because once the  datastore is reset to factory-default, the device 
would not be reachable.  I don’t know where we landed on that.  However, I 
think some attention should be paid to things like zero-touch provisioning.  If 
I reset to factory-default, I would expect the device to undergo any 
out-of-the-box bootstrapping.  Perhaps adding some text that after the RPC is 
executed, the device SHOULD perform any initial bootstrapping processes?

Perhaps the draft could say something like:

"...resets the configuration to the device's factory default configuration, for 
the OS version it is running.  For devices supporting zero touch bootstrapping 
mechanisms, the factory default configuration causes the bootstrapping process 
to execute."

[Qin]:Thanks Kent, how about the following proposed changes:
OLD TEXT:
“
Section 2

In addition, the "factory-reset" RPC might also be used
   to trigger some other restoring and resetting tasks such as files
   cleanup, restarting the node or some of the software processes,
   setting some security data/passwords to the default value, removing
   logs, or removing any temporary data (from datastore or elsewhere),
   etc.  When and why these tasks are triggered is not the scope of this
   document.
”
NEW TEXT:
“
Section 2



   For the server supporting zero touch bootstrapping mechanisms, the

   factory default configuration causes the bootstrapping process to

   execute, e.g.,the server might reset configuration to device's factory

   default configuration, for the version of operating system software it

   is running.  In addition, the "factory-reset" RPC might also be used

   to trigger some other restoring and resetting tasks such as files

   cleanup, restarting the node or some of the software processes,

   setting some security data/passwords to the default value, removing

   logs, or removing any temporary data (from datastore or elsewhere),

   etc.  When and why these tasks are triggered is not the scope of this
   document.
”
“restarting the node or some of the software processes” description may be a 
little bit duplicated since
we have already had separate initial bootstrapping process description before 
the sentence “In addition, the “facory-reret”…”

Kent // contributor

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-ietf-netmod-factory-default-04.txt

[Qin Wu]

Hi, Joe:
Thanks for your valuable comments, see reply inline below.
-邮件原件-
发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com] 
发送时间: 2019年10月28日 22:13
收件人: Qin Wu 
抄送: netmod@ietf.org
主题: Re: [netmod] New Version Notification for 
draft-ietf-netmod-factory-default-04.txt



> On Oct 27, 2019, at 23:37, Qin Wu  wrote:
> 
> v-04 is posted
> https://tools.ietf.org/html/draft-ietf-netmod-factory-default-04
> additional text to clarify rpc usage.

Thanks, Qin.  I re-read this latest draft, and albeit there were only a few 
changes, I have some broader comments.

First, I remember we talked about a reboot operation I think at the last 
IETF(?).  It was said that perhaps a reboot would happen as part of this RPC 
because once the  datastore is reset to factory-default, the device 
would not be reachable.  I don’t know where we landed on that.  However, I 
think some attention should be paid to things like zero-touch provisioning.  If 
I reset to factory-default, I would expect the device to undergo any 
out-of-the-box bootstrapping.  Perhaps adding some text that after the RPC is 
executed, the device SHOULD perform any initial bootstrapping processes?

[Qin]:Yes, initial bootstrapping processes should be covered, I will propose 
text in the separate email for this.

===

In Section 2, perhaps for clarity say that, “Factory-default content SHALL be 
specified by one of the following means in descending order of precedence”?  
I’m nit-picking on this one, though.

[Qin]: okay, fixed.
===

In Section 2, you mention Instance Data is second in the list.  What is really 
meant by this?  Does that mean the factory-default config is defined by an 
instance data file specified by the vendor in some offline location?  If so, 
perhaps it’s worth clarifying that.
[Qin]: How about the following proposed changes:
OLD TEXT
"
YANG Instance Data [I-D.ietf-netmod-yang-instance-file-format]
"
NEW TEXT:
"
  by vendors using YANG Instance Data 
[I-D.ietf-netmod-yang-instance-file-format] file format in
  vendor's website or other places where off-line document is kept;
"

===

In Section 2 and in the YANG module description for the RPC your tenses don’t 
match.  You should say:

Upon receiving the RPC the server resets the contents of all read-write 
configuration datastore (e.g.,  and ) to their 
factory-default contents.

[Qin]:Good catch, fixed.
===

In Section 2, you say, “some of the SW processes”.  I think you mean software.  
You should expand SW.
[Qin]:Fixed.

Joe

> 
> -Qin
> -邮件原件-
> 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
> 发送时间: 2019年10月28日 11:36
> 收件人: Niuye ; Qin Wu ; Qin Wu 
> ; Balazs Lengyel 
> 主题: New Version Notification for draft-ietf-netmod-factory-default-04.txt
> 
> 
> A new version of I-D, draft-ietf-netmod-factory-default-04.txt
> has been successfully submitted by Qin Wu and posted to the IETF repository.
> 
> Name: draft-ietf-netmod-factory-default
> Revision: 04
> Title:Factory Default Setting
> Document date:2019-10-26
> Group:netmod
> Pages:11
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-netmod-factory-default-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-netmod-factory-default-04
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-04
> 
> Abstract:
>   This document defines a method to reset a server to its factory-
>   default content.  The reset operation may be used e.g. during initial
>   zero-touch configuration or when the existing configuration has major
>   errors, so re-starting the configuration process from scratch is the
>   best option.
> 
>   A new factory-reset RPC is defined.  Several methods of documenting
>   the factory-default content are specified.
> 
>   Optionally a new "factory-default" read-only datastore is defined,
>   that contains the data that will be copied over to the running
>   datastore at reset.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] [Errata Rejected] RFC7950 (5879)

[RFC Errata System]

The following errata report has been rejected for RFC7950,
"The YANG 1.1 Data Modeling Language".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5879

--
Status: Rejected
Type: Technical

Reported by: Ladislav Lhotka 
Date Reported: 2019-10-22
Rejected by: Ignas Bagdonas (IESG)

Section: 3

Original Text
-
o  schema tree: The definition hierarchy specified within a module.


Corrected Text
--
o  schema tree: The hierarchy of schema nodes defined in the set of all modules 
   implemented by a server, as specified in the YANG library data [RFC7895].



Notes
-
The original definition of the term has two problems:

1. Schema tree is not limited to a single module. Some YANG constructs, such as 
augment and leafref type, may refer to a schema node that is defined in another 
module.

2. Apart from schema nodes, YANG modules contain definitions that do not 
contribute to the schema tree: groupings, typedefs, identities etc.
 --VERIFIER NOTES-- 
   Rejected based on WG discussion: 
https://mailarchive.ietf.org/arch/msg/netmod/5uDEBwgNehfLaPONpDSjVnCcWx8


--
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--
Title   : The YANG 1.1 Data Modeling Language
Publication Date: August 2016
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-ietf-netmod-factory-default-04.txt

[Joe Clarke (jclarke)]

On Oct 28, 2019, at 11:54, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:


Regarding this point:

First, I remember we talked about a reboot operation I think at the last 
IETF(?).  It was said that perhaps a reboot would happen as part of this RPC 
because once the  datastore is reset to factory-default, the device 
would not be reachable.  I don’t know where we landed on that.  However, I 
think some attention should be paid to things like zero-touch provisioning.  If 
I reset to factory-default, I would expect the device to undergo any 
out-of-the-box bootstrapping.  Perhaps adding some text that after the RPC is 
executed, the device SHOULD perform any initial bootstrapping processes?

Perhaps the draft could say something like:

"...resets the configuration to the device's factory default configuration, for 
the OS version it is running.  For devices supporting zero touch bootstrapping 
mechanisms, the factory default configuration causes the bootstrapping process 
to execute."

Works for me.

Joe


Kent // contributor


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-ietf-netmod-factory-default-04.txt

[Kent Watsen]

Regarding this point:

> First, I remember we talked about a reboot operation I think at the last 
> IETF(?).  It was said that perhaps a reboot would happen as part of this RPC 
> because once the  datastore is reset to factory-default, the device 
> would not be reachable.  I don’t know where we landed on that.  However, I 
> think some attention should be paid to things like zero-touch provisioning.  
> If I reset to factory-default, I would expect the device to undergo any 
> out-of-the-box bootstrapping.  Perhaps adding some text that after the RPC is 
> executed, the device SHOULD perform any initial bootstrapping processes?

Perhaps the draft could say something like:

"...resets the configuration to the device's factory default configuration, for 
the OS version it is running.  For devices supporting zero touch bootstrapping 
mechanisms, the factory default configuration causes the bootstrapping process 
to execute."

Kent // contributor

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] x509c2n:cert-to-name problem

[Kent Watsen]

Hi Martin,


> I'll check with my co-author and get back.

Thanks.


> No, in many SMIv2 objects, a zero-length value is used for optional
> nodes (due to the way the protocol (SNMP) works).  In YANG we don't do
> this, since the protocls (NETCONF etc) can handle non-existing
> optional leafs.

In that case, there might be two issues:

1) the description statement excluding CA certs (mentioned before)
2) `mandatory true` should be `mandatory false` ?

Kent // contributor


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-ietf-netmod-factory-default-04.txt

[Joe Clarke (jclarke)]

> On Oct 27, 2019, at 23:37, Qin Wu  wrote:
> 
> v-04 is posted
> https://tools.ietf.org/html/draft-ietf-netmod-factory-default-04
> additional text to clarify rpc usage.

Thanks, Qin.  I re-read this latest draft, and albeit there were only a few 
changes, I have some broader comments.

First, I remember we talked about a reboot operation I think at the last 
IETF(?).  It was said that perhaps a reboot would happen as part of this RPC 
because once the  datastore is reset to factory-default, the device 
would not be reachable.  I don’t know where we landed on that.  However, I 
think some attention should be paid to things like zero-touch provisioning.  If 
I reset to factory-default, I would expect the device to undergo any 
out-of-the-box bootstrapping.  Perhaps adding some text that after the RPC is 
executed, the device SHOULD perform any initial bootstrapping processes?

===

In Section 2, perhaps for clarity say that, “Factory-default content SHALL be 
specified by one of the following means in descending order of precedence”?  
I’m nit-picking on this one, though.

===

In Section 2, you mention Instance Data is second in the list.  What is really 
meant by this?  Does that mean the factory-default config is defined by an 
instance data file specified by the vendor in some offline location?  If so, 
perhaps it’s worth clarifying that.

===

In Section 2 and in the YANG module description for the RPC your tenses don’t 
match.  You should say:

Upon receiving the RPC the server resets the contents of all read-write 
configuration datastore (e.g.,  and ) to their 
factory-default contents.

===

In Section 2, you say, “some of the SW processes”.  I think you mean software.  
You should expand SW.

Joe

> 
> -Qin
> -邮件原件-
> 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
> 发送时间: 2019年10月28日 11:36
> 收件人: Niuye ; Qin Wu ; Qin Wu 
> ; Balazs Lengyel 
> 主题: New Version Notification for draft-ietf-netmod-factory-default-04.txt
> 
> 
> A new version of I-D, draft-ietf-netmod-factory-default-04.txt
> has been successfully submitted by Qin Wu and posted to the IETF repository.
> 
> Name: draft-ietf-netmod-factory-default
> Revision: 04
> Title:Factory Default Setting
> Document date:2019-10-26
> Group:netmod
> Pages:11
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-netmod-factory-default-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-netmod-factory-default-04
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-04
> 
> Abstract:
>   This document defines a method to reset a server to its factory-
>   default content.  The reset operation may be used e.g. during initial
>   zero-touch configuration or when the existing configuration has major
>   errors, so re-starting the configuration process from scratch is the
>   best option.
> 
>   A new factory-reset RPC is defined.  Several methods of documenting
>   the factory-default content are specified.
> 
>   Optionally a new "factory-default" read-only datastore is defined,
>   that contains the data that will be copied over to the running
>   datastore at reset.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> 
> > On Oct 23, 2019, at 4:18 AM, Martin Bjorklund  wrote:
> > 
> > Hi,
> > 
> > Since this is a problem with ietf-x509-cert-to-name I reply to this
> > question here, rather than buried in a reply to another issue for
> > another document ;-)
> > 
> > Kent Watsen  wrote:
> >> Separately, I just noticed an issue with the
> >> `ietf-[net/rest]conf-server` modules using x509c2n:cert-to-name.
> >> 
> >> ```
> >> leaf fingerprint {
> >>   type x509c2n:tls-fingerprint;
> >>   mandatory true;
> >>   description
> >> "Specifies a value with which the fingerprint of the
> >>  full certificate presented by the peer is compared.  If
> >>  the fingerprint of the full certificate presented by the
> >>  peer does not match the fingerprint configured, then the
> >>  entry is skipped, and the search for a match continues.";
> >> ```
> >> 
> >> This definition seems to exclude authenticating client certificates
> >> via a trust anchor certificate as, if one can configure a fingerprint,
> >> then one could also configure the whole certificate (e.g.,
> >> `tls-server-parameters/client-authentication/client-certs`), thus
> >> obviating the need for
> >> `tls-server-parameters/client-authentication/ca-certs`.
> > 
> > [...]
> > 
> >> A better definition (I think) would've been:
> >> 
> >> ```
> >> OLD: full certificate presented by the peer 
> >> NEW: full certificate of the certificate used to authenticate the
> >> certificate presented by the peer, which MAY be the peer's end-entity
> >> certificate.
> >> ```
> > 
> > Hmm, I think you found an inconsisteny in this module.  Note that the
> > description of the list itself has:
> > 
> > The cert-to-name entry's fingerprint
> > determines whether the list entry is a match:
> > 
> > 1) If the cert-to-name list entry's fingerprint value
> >matches that of the presented certificate, then consider
> >the list entry a successful match.
> > 
> > 2) If the cert-to-name list entry's fingerprint value
> >matches that of a locally held copy of a trusted CA
> >certificate, and that CA certificate was part of the CA
> >certificate chain to the presented certificate, then
> >consider the list entry a successful match.
> > 
> > Also note:
> > 
> >Security administrators are encouraged to make use of
> >certificates with subjectAltName fields that can be mapped to
> >names so that a single root CA certificate can allow all
> >child certificates' subjectAltName fields to map directly to
> >a name via a 1:1 transformation.
> > 
> > So I think this is a bug in the description of "leaf fingerprint".
> 
> I'd rather it be that than a bug in "list cert-to-name".  Would an
> erratum be appropriate here?  While the fix effectively changes the
> meaning of "fingerprint", it only would do so in order to resolve the
> inconsistency, and thus seems necessary.
> 
> Martin, if you agree, would to like to propose text or go straight to
> submitting an erratum?

I'll check with my co-author and get back.

> >> I note that `fingerprint` may be 0 characters in length, which is what
> >> netconf/restconf servers wanting to support authenticating clients via
> >> a trust anchor will need to do in their configurations.  I'll update
> >> the examples in those drafts to include an empty `fingerprint` node.
> > 
> > But 0-length fingerprint won't match anything, which means you won't
> > get a user name and the client can't be authenticated, and the session
> > dropped.
> 
> Actually, I thought that this was on purpose, as SnmpTLSFingerprint in
> RFC 6353 (referenced by "typedef tls-fingerprint" says (note the 3rd
> paragraph):
> 
> SnmpTLSFingerprint ::= TEXTUAL-CONVENTION
> DISPLAY-HINT "1x:1x"
> STATUS   current
> DESCRIPTION
>"A fingerprint value that can be used to uniquely reference
>other data of potentially arbitrary length.
> 
>An SnmpTLSFingerprint value is composed of a 1-octet hashing
>algorithm identifier followed by the fingerprint value.  The
>octet value encoded is taken from the IANA TLS HashAlgorithm
>Registry (RFC 5246).  The remaining octets are filled using the
>results of the hashing algorithm.
> 
>This TEXTUAL-CONVENTION allows for a zero-length (blank)
>SnmpTLSFingerprint value for use in tables where the
>fingerprint value may be optional.  MIB definitions or
>implementations may refuse to accept a zero-length value as
>appropriate."
>REFERENCE "RFC 5246: The Transport Layer
>   Security (TLS) Protocol Version 1.2
>   http://www.iana.org/assignments/tls-parameters/
>"
> SYNTAX OCTET STRING (SIZE (0..255))
> 
> Does it not have the same meaning?

No, in many SMIv2 objects, 

Re: [netmod] Effect of ordered by user on state(config false) list

[Schönwälder , Jürgen]

On Mon, Oct 28, 2019 at 08:42:57AM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Tarek Saad  wrote:
> > Hi,
> > 
> > We are wondering if “ordered by user” has any effect on a (config
> > false)/state list?
> > Given RFC6020 specifies “ordered by system” as the default order, does
> > this mean it is the order assumed for a state list with “ordered by
> > user”?
> 
> There is no effect "on the wire"; the entries are sent in the order
> determined by the server in both cases.  But it informs to the
> consumer of the data model that the order of the list entries carries
> some meaning.
>

For operational is always about what the system actually does.

For ordered by user entries configured by intended, the order of
entries used by the system should be the order defined by the users
but ultimately operational needs to report what is actually used. (If
a system fails to honor ordered by user, this should be visible from
comparing operational and intended. This is essential for debugging.)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Effect of ordered by user on state(config false) list

[Martin Bjorklund]

Hi,

Tarek Saad  wrote:
> Hi,
> 
> We are wondering if “ordered by user” has any effect on a (config
> false)/state list?
> Given RFC6020 specifies “ordered by system” as the default order, does
> this mean it is the order assumed for a state list with “ordered by
> user”?

There is no effect "on the wire"; the entries are sent in the order
determined by the server in both cases.  But it informs to the
consumer of the data model that the order of the list entries carries
some meaning.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod