From eb41edddbbc293593c5daed4a4882f59d09ea32b Mon Sep 17 00:00:00 2001 From: Lou Berger Date: Mon, 20 Feb 2017 19:09:45 -0500 Subject: [PATCH 1/3] Add comments re inline and tree representations --- draft-ietf-netmod-schema-mount.org | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/draft-ietf-netmod-schema-mount.org b/draft-ietf-netmod-schema-mount.org index 3d1b190..257d74a 100644 --- a/draft-ietf-netmod-schema-mount.org +++ b/draft-ietf-netmod-schema-mount.org @@ -625,6 +625,9 @@ with the "inline" method only (with no "schema-mounts" data), and using schema node identifiers as described in ^sni^ for the "use-schema" case. +An additional consideration is if there should be any special indication +of mount points what will always, or never, be of type "inline". + ** Parent References As explained in ^parref^, references to the parent schema can only be @@ -660,6 +663,16 @@ The first two requirements seem rather restrictive. On the other hand, the last one is difficult to guarantee - for example, things can break after an augment within the mounted schema. +** Tree Representations + +Need to decide on how to represent mount points in trees. + +Also, should decide if modules required under inline mount points should +be represented in any specific fashion, and if so what yang statements +drives this. For example, YANG library is required under all inline +mount points, and it's possible that other mounted schemas could be +required at parent module design time. + {{document: name ; ipr trust200902; From db5e13501222102475fa7a5096a4102919fa4bdf Mon Sep 17 00:00:00 2001 From: Lou Berger Date: Wed, 22 Feb 2017 10:09:22 -0500 Subject: [PATCH 2/3] revised text per discussion with Lada --- draft-ietf-netmod-schema-mount.org | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/draft-ietf-netmod-schema-mount.org b/draft-ietf-netmod-schema-mount.org index 257d74a..219015c 100644 --- a/draft-ietf-netmod-schema-mount.org +++ b/draft-ietf-netmod-schema-mount.org @@ -625,9 +625,6 @@ with the "inline" method only (with no "schema-mounts" data), and using schema node identifiers as described in ^sni^ for the "use-schema" case. -An additional consideration is if there should be any special indication -of mount points what will always, or never, be of type "inline". - ** Parent References As explained in ^parref^, references to the parent schema can only be @@ -671,7 +668,8 @@ Also, should decide if modules required under inline mount points should be represented in any specific fashion, and if so what yang statements drives this. For example, YANG library is required under all inline mount points, and it's possible that other mounted schemas could be -required at parent module design time. +required at parent module design time. This implies that there +is an indication that a mount point is of type "inline". {{document: name ; From c5c6ed31ab2e631fe5935d641fea6d9374d34882 Mon Sep 17 00:00:00 2001 From: Lou Berger Date: Wed, 22 Feb 2017 10:38:59 -0500 Subject: [PATCH 3/3] 2nd try at revised text per discussion with Lada --- draft-ietf-netmod-schema-mount.org | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/draft-ietf-netmod-schema-mount.org b/draft-ietf-netmod-schema-mount.org index 219015c..52f46bc 100644 --- a/draft-ietf-netmod-schema-mount.org +++ b/draft-ietf-netmod-schema-mount.org @@ -664,12 +664,23 @@ after an augment within the mounted schema. Need to decide on how to represent mount points in trees. -Also, should decide if modules required under inline mount points should -be represented in any specific fashion, and if so what yang statements -drives this. For example, YANG library is required under all inline -mount points, and it's possible that other mounted schemas could be -required at parent module design time. This implies that there -is an indication that a mount point is of type "inline". +** Design Time Mounts + +The document currently doesn't allow for design time mounts. Design time +mounts have been identified as possibly for multiple cases, and it may +be worthwhile to identify a minimum or complete set of modules that must +be supported under a mount point. This could be used in service modules +that want to allow for configuration of device-specific information. +The document could be modified to either (a) not preclude design time +mounts, but not fully specify their support, or (b) fully define their +support. + +Also if/when design time mounts are supported, it could be possible to +represent both mounts points and their required modules in tree +representations and support for such would need to be defined. For +example, YANG library is required under all inline mount points, and +it's possible that other mounted schemes could be required at parent +module design time. {{document: name ;