Re: Yangdoctors last call review of draft-ietf-bfd-yang-09

[Juergen Schoenwaelder]

On Sun, Mar 04, 2018 at 02:12:30PM +, Reshad Rahman (rrahman) wrote:
> 
> We have made the changes in revs 10 and 11 to address your comments . The 
> exception is module ietf-bfd-types which did not get renamed per reason below.
>

Hi,

here is my re-review of draft-ietf-bfd-yang. I think the document has
significantly improved since the -09 version, the authors have done an
excellent job to improve the document quality.

I have mostly a few minor mostly editorial issues left, except the
first one, which concerns the schema mount use case.

- Thanks for clarifying that the modules can be used on standalone
  devices. The new text is helpful.

  For the LNE and NI use cases, does it make sense to detail the mount
  points that are used? My understanding is that schema mount requires
  that mount points are identified with a "mount-point" extension
  statement, i.e., you can't mount at arbitrary places in the
  hierarchy but only at places that have been designated as mount
  points.

  That all said, since your YANG modules are basically augmenting
  other YANG modules that may be mounted, you do not seem to need a
  separate schema mount. If my understanding is correct, then here is
  a starting point for making this clearer:

  OLD

When used at the network device level, the BFD YANG model is used
"as-is".  When the BFD model is to be used in a Logical Network
Element or in a Network Instance, the approach taken is to do a
schema-mount (see Schema Mount [I-D.ietf-netmod-schema-mount]) of the
BFD model in the appropriate location.  For example, if an
implementation supports BFD IP multihop in network instances, the
implementation would do schema-mount of the BFD IP multihop model in
a mount-point which resides in a network instance.

  NEW

When used at the network device level, the BFD YANG model are used
"as-is".  When the BFD YANG model is used in a Logical Network
Element or in a Network Instance, then the BFD YANG model augments
the mounted routing model for the Logical Network Element or the
Network Instance.

  Note that with this change, you also do not need a reference to
  schema mount.
  
- Since the different use cases (device, LNE, NI) are discussed right
  at the beginning of Section 2, it seems the following statements in
  Sections 2.5, 2.6, 2.7, 2.8, 2.9 are not really needed:

   The "bfd" node under control-plane-
   protocol can be used in a network device (top-level), or mounted in
   an LNE or in a network instance.

The "ip-sh" node can be used
   in a network device (top-level), or mounted in an LNE or in a network
   instance.

The "ip-mh"
   node can be used in a network device (top-level), or mounted in an
   LNE or in a network instance.

  The "lag" node can be used in a network
   device (top-level), or mounted in an LNE or in a network instance.

 The "mpls"
   node can be used in a network device (top-level), or mounted in an
   LNE or in a network instance.

- The text at the beginning of Section 2.13 should also mention RFC
  8177 since you are importing it.

- It might be useful to give more explicit instructions to IANA. I
  assume you want IANA to update the iana-bfd-types module whenever
  changes are made to the "BFD Diagnostic Codes" registry and "BFD
  Authentication Types" registries. Giving clear instructions what
  IANA is expected to do and when is better than a soft statement such
  as "intended to reflect". But IANA is going to ask questions about
  this anyway during their review I assume.

- The feature definitions in ietf-bfd-types have text of the form "as
  defined in RFC 5880" and perhaps it makes sense to add reference
  statements to these feature definitions. There are also a number of
  identities that say "as per RFC 588X" where perhaps reference
  statements should be added.

- The text at the beginning of Section 2.13 should also mention RFC
  6991 since you are importing it. And you are also importing from
  RFC  (the routing model).

- The text at the beginning of Section 2.16 should also mention
  that you import from RFC  (the routing model).

- The text at the beginning of Section 2.17 should also mention that
  you import from RFC 6991 and from RFC  (the routing model).

- The text at the beginning of Section 2.18 should also mention that
  you import from RFC  (the routing model).

- The text at the beginning of Section 2.19 should also mention that
  you import from RFC  (the routing model).

- I have not validated the examples - I hope the authors have done so.
  They look more plausible than in the previous version I reviewed.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 

Re: Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Hi Jurgen,

We have made the changes in revs 10 and 11 to address your comments . The 
exception is module ietf-bfd-types which did not get renamed per reason below.

Regards,
Reshad.

On 2018-02-25, 11:28 AM, "Reshad Rahman (rrahman)"  wrote:

Hi,

Regarding the following, making the change is easy but ietf-bfd-types is 
used by other modules so this will impact these other modules. E.g. the RIP 
draft (https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/) is 
currently in the RFC Editor queue, I presume it's too late then to make this 
name change?

Regards,
Reshad.

* BFD types YANG Module

  -  In fact, ietf-bfd-types is kind of a
misnomer; perhaps this should be ietf-bfd-common (the -common 
was
used in RFC 8194 but I am biased here).
 Will rename to -common


On 2018-02-23, 11:53 AM, "Reshad Rahman (rrahman)"  
wrote:

Hi Jürgen,

Thank you for the review, response inline.

On 2018-02-15, 4:35 AM, "Jürgen Schönwälder" 
 wrote:

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Review of draft-ietf-bfd-yang-09.txt.

* General comments

  - Having requirements language below the abstract looks like a 
novel
idea, I assume the RFC editor will edit this. Also note that
nowadays authors are usually expected to cite RFC 8174 as well
with the extended boilerplate text.
 Will make the changes.

  - Update 2017 to 2018 in copyright statements etc.
 Will make the changes.

  - References to RFC 7223, RFC 7277, RFC 8022 should be updated to
references to the I-Ds replacing them (sitting in the RFC editor
queue). This may also involve changes in the YANG model.
 Will make the changes. I don't think this will involve changes in 
the YANG model, but will pay attention to this.

  - State whether the model is NMDA compliant (which it likely 
should
be), see also previous item.
 This is mentioned in section 2. I will look into moving this to 
the intro and changing the text to clarify.

  - I am not sure why you want to cite I-D.dsdt-nmda-guidelines. 
Would
it not make more sense to cite the NMDA specification?
 Will make the change. By NMDA specification, you're referring to 
draft-ietf-netmod-revised-datastores?

  - There are some YANG validation errors that should be addressed 
(see
the link on the datatracker).
 Those were in 8022bis I believe, gone now.

  - References YANG modules must be in the references and there must
be citations in the text, hence there is the common phrase "This
YANG module imports  [RFCwxyz] and "

  - We generally prefer

  reference "RFC 6991: Common YANG Data Types"

over

  reference "RFC 6991"

since not everybody remembers all the RFC numbers (add the RFC
title after the RFC number, separated by a colon). In some 
places
you actually use the syntactic format but you do not use the RFC
title. Please make this consistent, following the usual
conventions.
 Will make the change. 

  - I have raised a question on yang-doctors concerning the pattern

  import ietf-inet-types {
prefix "inet";
reference "RFC 6991";
  }

and whether this should perhaps be

  import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types
   (at the time of this writing)";
  }
  Saw the discussion, will make the change once there is closure.

* Design of the Data Model

  - Do I always have to use schema mount to use these YANG models? 
If
so, one might consider I-D.ietf-netmod-schema-mount a normative
reference. Are you not augmenting the routing model?
   I will clarify in the text. There was a follow-up email 
discussion on this, we are augmenting the routing model and schema mount can be 
used (but not mandatory).
  
  - I do not understand the explanations how the groupings solve the
problem that IGPs are moving 

Re: Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Hi,

Regarding the following, making the change is easy but ietf-bfd-types is used 
by other modules so this will impact these other modules. E.g. the RIP draft 
(https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/) is currently in 
the RFC Editor queue, I presume it's too late then to make this name change?

Regards,
Reshad.

* BFD types YANG Module

  -  In fact, ietf-bfd-types is kind of a
misnomer; perhaps this should be ietf-bfd-common (the -common was
used in RFC 8194 but I am biased here).
 Will rename to -common


On 2018-02-23, 11:53 AM, "Reshad Rahman (rrahman)"  wrote:

Hi Jürgen,

Thank you for the review, response inline.

On 2018-02-15, 4:35 AM, "Jürgen Schönwälder" 
 wrote:

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Review of draft-ietf-bfd-yang-09.txt.

* General comments

  - Having requirements language below the abstract looks like a novel
idea, I assume the RFC editor will edit this. Also note that
nowadays authors are usually expected to cite RFC 8174 as well
with the extended boilerplate text.
 Will make the changes.

  - Update 2017 to 2018 in copyright statements etc.
 Will make the changes.

  - References to RFC 7223, RFC 7277, RFC 8022 should be updated to
references to the I-Ds replacing them (sitting in the RFC editor
queue). This may also involve changes in the YANG model.
 Will make the changes. I don't think this will involve changes in the 
YANG model, but will pay attention to this.

  - State whether the model is NMDA compliant (which it likely should
be), see also previous item.
 This is mentioned in section 2. I will look into moving this to the 
intro and changing the text to clarify.

  - I am not sure why you want to cite I-D.dsdt-nmda-guidelines. Would
it not make more sense to cite the NMDA specification?
 Will make the change. By NMDA specification, you're referring to 
draft-ietf-netmod-revised-datastores?

  - There are some YANG validation errors that should be addressed (see
the link on the datatracker).
 Those were in 8022bis I believe, gone now.

  - References YANG modules must be in the references and there must
be citations in the text, hence there is the common phrase "This
YANG module imports  [RFCwxyz] and "

  - We generally prefer

  reference "RFC 6991: Common YANG Data Types"

over

  reference "RFC 6991"

since not everybody remembers all the RFC numbers (add the RFC
title after the RFC number, separated by a colon). In some places
you actually use the syntactic format but you do not use the RFC
title. Please make this consistent, following the usual
conventions.
 Will make the change. 

  - I have raised a question on yang-doctors concerning the pattern

  import ietf-inet-types {
prefix "inet";
reference "RFC 6991";
  }

and whether this should perhaps be

  import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types
   (at the time of this writing)";
  }
  Saw the discussion, will make the change once there is closure.

* Design of the Data Model

  - Do I always have to use schema mount to use these YANG models? If
so, one might consider I-D.ietf-netmod-schema-mount a normative
reference. Are you not augmenting the routing model?
   I will clarify in the text. There was a follow-up email discussion 
on this, we are augmenting the routing model and schema mount can be used (but 
not mandatory).
  
  - I do not understand the explanations how the groupings solve the
problem that IGPs are moving targets (they come and go). How do
the groupings help the operator to configure BFD parameters for
peers they do not know about yet?
 I will update the text. Basically as IGPs discover peers/neighbors, 
they create BFD sessions "internally" (i.e. via API, not via config).

  - How does a client know which choices of the "min-interval", used
for both transmit and receive intervals, and "desired-min-tx-
interval" and "required-min-rx-interval" are supported by an
implementation?
  We'll think about this. We'll either add feature or make both 
mandatory.
   
  - The phrase 

Re: Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Hi Jürgen,

Thank you for the review, response inline.

On 2018-02-15, 4:35 AM, "Jürgen Schönwälder" 
 wrote:

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Review of draft-ietf-bfd-yang-09.txt.

* General comments

  - Having requirements language below the abstract looks like a novel
idea, I assume the RFC editor will edit this. Also note that
nowadays authors are usually expected to cite RFC 8174 as well
with the extended boilerplate text.
 Will make the changes.

  - Update 2017 to 2018 in copyright statements etc.
 Will make the changes.

  - References to RFC 7223, RFC 7277, RFC 8022 should be updated to
references to the I-Ds replacing them (sitting in the RFC editor
queue). This may also involve changes in the YANG model.
 Will make the changes. I don't think this will involve changes in the YANG 
model, but will pay attention to this.

  - State whether the model is NMDA compliant (which it likely should
be), see also previous item.
 This is mentioned in section 2. I will look into moving this to the intro 
and changing the text to clarify.

  - I am not sure why you want to cite I-D.dsdt-nmda-guidelines. Would
it not make more sense to cite the NMDA specification?
 Will make the change. By NMDA specification, you're referring to 
draft-ietf-netmod-revised-datastores?

  - There are some YANG validation errors that should be addressed (see
the link on the datatracker).
 Those were in 8022bis I believe, gone now.

  - References YANG modules must be in the references and there must
be citations in the text, hence there is the common phrase "This
YANG module imports  [RFCwxyz] and "

  - We generally prefer

  reference "RFC 6991: Common YANG Data Types"

over

  reference "RFC 6991"

since not everybody remembers all the RFC numbers (add the RFC
title after the RFC number, separated by a colon). In some places
you actually use the syntactic format but you do not use the RFC
title. Please make this consistent, following the usual
conventions.
 Will make the change. 

  - I have raised a question on yang-doctors concerning the pattern

  import ietf-inet-types {
prefix "inet";
reference "RFC 6991";
  }

and whether this should perhaps be

  import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types
   (at the time of this writing)";
  }
  Saw the discussion, will make the change once there is closure.

* Design of the Data Model

  - Do I always have to use schema mount to use these YANG models? If
so, one might consider I-D.ietf-netmod-schema-mount a normative
reference. Are you not augmenting the routing model?
   I will clarify in the text. There was a follow-up email discussion on 
this, we are augmenting the routing model and schema mount can be used (but not 
mandatory).
  
  - I do not understand the explanations how the groupings solve the
problem that IGPs are moving targets (they come and go). How do
the groupings help the operator to configure BFD parameters for
peers they do not know about yet?
 I will update the text. Basically as IGPs discover peers/neighbors, they 
create BFD sessions "internally" (i.e. via API, not via config).

  - How does a client know which choices of the "min-interval", used
for both transmit and receive intervals, and "desired-min-tx-
interval" and "required-min-rx-interval" are supported by an
implementation?
  We'll think about this. We'll either add feature or make both mandatory.
   
  - The phrase 'operational model' probably means 'operational state
model' and 'operational items' probably means 'operational state
data'.
 Will make the change. 

  - You have summary information and detailed BFD session information.
What would an implementation report if say access to some BFD
sessions is restricted by access control? Would information about
them still leak through the summary information? I assume so that
this may be practically the way to do things but perhaps this
needs to be mentioned in the security considerations.
 The summary information contains everything. I don't see what kind of 
security consideration is required if we know e.g. that we have so many 
sessions up and down.

  - In 2.3, you use 'clients of BFD' but I think this is very
different from 'BFD clients'. Please clarify the terminology.
 Will use 'BFD clients' everywhere.

  - s/operational data/operational state data/g
 Yes

  - The *-count leafs seem to be 

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Jeffrey Haas]

On Sun, Feb 18, 2018 at 03:28:13AM +, Reshad Rahman (rrahman) wrote:
> Hi Acee,
> 
> What I meant is that BFD always augments the control palne protocols in 
> ietf-routing model. And the BFD augmentation can be used as-is or mounted in 
> LNE or in NI.

Basically:
Whereever ietf-routing is, BFD may also be.

BFD may not be everywhere that ietf-routing is (e.g. it may or may not be in
an instance, depending on device capabilities).

-- Jeff

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Hi Acee,

What I meant is that BFD always augments the control palne protocols in 
ietf-routing model. And the BFD augmentation can be used as-is or mounted in 
LNE or in NI.

Regards,
Reshad.

On 2018-02-17, 7:46 PM, "Acee Lindem (acee)"  wrote:

Hi Reshad, 
Are you saying that BFD would never augment the list of control place 
protocols in ietf-routing and always be at the root of the tree (whether it be 
the device, LNE, or NI)? I guess it doesn't have to be in the list since it 
will never install routes in the routing table. 

Thanks,
Acee

On 2/17/18, 5:26 PM, "Reshad Rahman (rrahman)"  wrote:

Ietf-bfd augments the ietf-routing model, that's not conditional. How 
the ietf-bfd model is used may vary:
1) It may be used "directly" in a device (i.e no schema mount)
2) It may be schema mounted for use in an LNE
3) It may be schema mounted for use in a VRF

I thought this was the case for all routing protocols.

Regards,
Reshad.

On 2018-02-17, 1:31 PM, "Acee Lindem (acee)"  wrote:

I thought about that after I replied. I guess you are saying that 
it is conceivable for a network device to support ietf-bfd but not support 
routing (ietf-routing)? 

Thanks,
Acee 

On 2/17/18, 1:24 PM, "Reshad Rahman (rrahman)"  
wrote:

Right, schema-mount can be used in some cases (logical device 
or in a VRF) but doesn’t have to be used in other cases (e.g. network device 
which doesn't support VRFs). We will clarify the text, at a certain time we 
incorrectly thought that schema mount had to be used in all cases.

Regards,
Reshad.

On 2018-02-17, 3:56 AM, "Juergen Schoenwaelder" 
 wrote:

On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem 
(acee) wrote:

> * Design of the Data Model
> 
>   - Do I always have to use schema mount to use these 
YANG models? If
> so, one might consider 
I-D.ietf-netmod-schema-mount a normative
> reference. Are you not augmenting the routing 
model?
> 
> This Is definitely not the case. This model will augment 
RFC8022BIS. The question on how to do is being discussion on the YANG doctors 
list. 
>

This is what I thought but the text is kind of misleading:

   BFD can operate in the following contexts:

   [...]

   The approach taken is to do a schema-mount (see Schema 
Mount
   [I-D.ietf-netmod-schema-mount]) of the BFD model in the 
appropriate
   locations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen 
gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 
Bremen | Germany
Fax:   +49 421 200 3103 

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Acee Lindem (acee)]

Hi Reshad, 
Are you saying that BFD would never augment the list of control place protocols 
in ietf-routing and always be at the root of the tree (whether it be the 
device, LNE, or NI)? I guess it doesn't have to be in the list since it will 
never install routes in the routing table. 

Thanks,
Acee

On 2/17/18, 5:26 PM, "Reshad Rahman (rrahman)"  wrote:

Ietf-bfd augments the ietf-routing model, that's not conditional. How the 
ietf-bfd model is used may vary:
1) It may be used "directly" in a device (i.e no schema mount)
2) It may be schema mounted for use in an LNE
3) It may be schema mounted for use in a VRF

I thought this was the case for all routing protocols.

Regards,
Reshad.

On 2018-02-17, 1:31 PM, "Acee Lindem (acee)"  wrote:

I thought about that after I replied. I guess you are saying that it is 
conceivable for a network device to support ietf-bfd but not support routing 
(ietf-routing)? 

Thanks,
Acee 

On 2/17/18, 1:24 PM, "Reshad Rahman (rrahman)"  
wrote:

Right, schema-mount can be used in some cases (logical device or in 
a VRF) but doesn’t have to be used in other cases (e.g. network device which 
doesn't support VRFs). We will clarify the text, at a certain time we 
incorrectly thought that schema mount had to be used in all cases.

Regards,
Reshad.

On 2018-02-17, 3:56 AM, "Juergen Schoenwaelder" 
 wrote:

On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem (acee) 
wrote:

> * Design of the Data Model
> 
>   - Do I always have to use schema mount to use these 
YANG models? If
> so, one might consider I-D.ietf-netmod-schema-mount a 
normative
> reference. Are you not augmenting the routing model?
> 
> This Is definitely not the case. This model will augment 
RFC8022BIS. The question on how to do is being discussion on the YANG doctors 
list. 
>

This is what I thought but the text is kind of misleading:

   BFD can operate in the following contexts:

   [...]

   The approach taken is to do a schema-mount (see Schema Mount
   [I-D.ietf-netmod-schema-mount]) of the BFD model in the 
appropriate
   locations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
Germany
Fax:   +49 421 200 3103 

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Ietf-bfd augments the ietf-routing model, that's not conditional. How the 
ietf-bfd model is used may vary:
1) It may be used "directly" in a device (i.e no schema mount)
2) It may be schema mounted for use in an LNE
3) It may be schema mounted for use in a VRF

I thought this was the case for all routing protocols.

Regards,
Reshad.

On 2018-02-17, 1:31 PM, "Acee Lindem (acee)"  wrote:

I thought about that after I replied. I guess you are saying that it is 
conceivable for a network device to support ietf-bfd but not support routing 
(ietf-routing)? 

Thanks,
Acee 

On 2/17/18, 1:24 PM, "Reshad Rahman (rrahman)"  wrote:

Right, schema-mount can be used in some cases (logical device or in a 
VRF) but doesn’t have to be used in other cases (e.g. network device which 
doesn't support VRFs). We will clarify the text, at a certain time we 
incorrectly thought that schema mount had to be used in all cases.

Regards,
Reshad.

On 2018-02-17, 3:56 AM, "Juergen Schoenwaelder" 
 wrote:

On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem (acee) wrote:

> * Design of the Data Model
> 
>   - Do I always have to use schema mount to use these YANG 
models? If
> so, one might consider I-D.ietf-netmod-schema-mount a 
normative
> reference. Are you not augmenting the routing model?
> 
> This Is definitely not the case. This model will augment 
RFC8022BIS. The question on how to do is being discussion on the YANG doctors 
list. 
>

This is what I thought but the text is kind of misleading:

   BFD can operate in the following contexts:

   [...]

   The approach taken is to do a schema-mount (see Schema Mount
   [I-D.ietf-netmod-schema-mount]) of the BFD model in the 
appropriate
   locations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
Germany
Fax:   +49 421 200 3103 

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Acee Lindem (acee)]

I thought about that after I replied. I guess you are saying that it is 
conceivable for a network device to support ietf-bfd but not support routing 
(ietf-routing)? 

Thanks,
Acee 

On 2/17/18, 1:24 PM, "Reshad Rahman (rrahman)"  wrote:

Right, schema-mount can be used in some cases (logical device or in a VRF) 
but doesn’t have to be used in other cases (e.g. network device which doesn't 
support VRFs). We will clarify the text, at a certain time we incorrectly 
thought that schema mount had to be used in all cases.

Regards,
Reshad.

On 2018-02-17, 3:56 AM, "Juergen Schoenwaelder" 
 wrote:

On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem (acee) wrote:

> * Design of the Data Model
> 
>   - Do I always have to use schema mount to use these YANG 
models? If
> so, one might consider I-D.ietf-netmod-schema-mount a 
normative
> reference. Are you not augmenting the routing model?
> 
> This Is definitely not the case. This model will augment RFC8022BIS. 
The question on how to do is being discussion on the YANG doctors list. 
>

This is what I thought but the text is kind of misleading:

   BFD can operate in the following contexts:

   [...]

   The approach taken is to do a schema-mount (see Schema Mount
   [I-D.ietf-netmod-schema-mount]) of the BFD model in the appropriate
   locations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Right, schema-mount can be used in some cases (logical device or in a VRF) but 
doesn’t have to be used in other cases (e.g. network device which doesn't 
support VRFs). We will clarify the text, at a certain time we incorrectly 
thought that schema mount had to be used in all cases.

Regards,
Reshad.

On 2018-02-17, 3:56 AM, "Juergen Schoenwaelder" 
 wrote:

On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem (acee) wrote:

> * Design of the Data Model
> 
>   - Do I always have to use schema mount to use these YANG models? If
> so, one might consider I-D.ietf-netmod-schema-mount a normative
> reference. Are you not augmenting the routing model?
> 
> This Is definitely not the case. This model will augment RFC8022BIS. The 
question on how to do is being discussion on the YANG doctors list. 
>

This is what I thought but the text is kind of misleading:

   BFD can operate in the following contexts:

   [...]

   The approach taken is to do a schema-mount (see Schema Mount
   [I-D.ietf-netmod-schema-mount]) of the BFD model in the appropriate
   locations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Juergen Schoenwaelder]

On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem (acee) wrote:

> * Design of the Data Model
> 
>   - Do I always have to use schema mount to use these YANG models? If
> so, one might consider I-D.ietf-netmod-schema-mount a normative
> reference. Are you not augmenting the routing model?
> 
> This Is definitely not the case. This model will augment RFC8022BIS. The 
> question on how to do is being discussion on the YANG doctors list. 
>

This is what I thought but the text is kind of misleading:

   BFD can operate in the following contexts:

   [...]

   The approach taken is to do a schema-mount (see Schema Mount
   [I-D.ietf-netmod-schema-mount]) of the BFD model in the appropriate
   locations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

Yangdoctors last call review of draft-ietf-bfd-yang-09

[Jürgen Schönwälder]

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Review of draft-ietf-bfd-yang-09.txt.

* General comments

  - Having requirements language below the abstract looks like a novel
idea, I assume the RFC editor will edit this. Also note that
nowadays authors are usually expected to cite RFC 8174 as well
with the extended boilerplate text.

  - Update 2017 to 2018 in copyright statements etc.

  - References to RFC 7223, RFC 7277, RFC 8022 should be updated to
references to the I-Ds replacing them (sitting in the RFC editor
queue). This may also involve changes in the YANG model.

  - State whether the model is NMDA compliant (which it likely should
be), see also previous item.

  - I am not sure why you want to cite I-D.dsdt-nmda-guidelines. Would
it not make more sense to cite the NMDA specification?

  - There are some YANG validation errors that should be addressed (see
the link on the datatracker).

  - References YANG modules must be in the references and there must
be citations in the text, hence there is the common phrase "This
YANG module imports  [RFCwxyz] and "

  - We generally prefer

  reference "RFC 6991: Common YANG Data Types"

over

  reference "RFC 6991"

since not everybody remembers all the RFC numbers (add the RFC
title after the RFC number, separated by a colon). In some places
you actually use the syntactic format but you do not use the RFC
title. Please make this consistent, following the usual
conventions.

  - I have raised a question on yang-doctors concerning the pattern

  import ietf-inet-types {
prefix "inet";
reference "RFC 6991";
  }

and whether this should perhaps be

  import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types
   (at the time of this writing)";
  }

* Design of the Data Model

  - Do I always have to use schema mount to use these YANG models? If
so, one might consider I-D.ietf-netmod-schema-mount a normative
reference. Are you not augmenting the routing model?

  - I do not understand the explanations how the groupings solve the
problem that IGPs are moving targets (they come and go). How do
the groupings help the operator to configure BFD parameters for
peers they do not know about yet?

  - How does a client know which choices of the "min-interval", used
for both transmit and receive intervals, and "desired-min-tx-
interval" and "required-min-rx-interval" are supported by an
implementation?

  - The phrase 'operational model' probably means 'operational state
model' and 'operational items' probably means 'operational state
data'.

  - You have summary information and detailed BFD session information.
What would an implementation report if say access to some BFD
sessions is restricted by access control? Would information about
them still leak through the summary information? I assume so that
this may be practically the way to do things but perhaps this
needs to be mentioned in the security considerations.

  - In 2.3, you use 'clients of BFD' but I think this is very
different from 'BFD clients'. Please clarify the terminology.

  - s/operational data/operational state data/g

  - The *-count leafs seem to be gauge32, should yang-types:gauge32 be
used?

  - There are also real counters that should probably use
yang-types:counter32 and yang-types:counter64 instead of uint32
and uint64.

  - Is [I-D.ietf-mpls-base-yang] not a normative reference? See text
in 2.11.3.

  - Is [I-D.ietf-teas-yang-te] not a normative reference? See text in
2.11.4.

* IANA BFD YANG Module

  - Fix the phrase "a collection of YANG data types considered defined
by IANA".

  - Does IANA understand how the typedefs diagnostic and auth-type is
to be managed?  Does this relate to an existing registry? Or is
this establishing a diagnostic registry? Should the last paragraph
in more clearly spell out that any changes to the existing
registry must lead to an update of the YANG module and that
updates to the YANG module are not allowed without an update to
the other registries? The current wording "intended to reflect"
seems vague. Should the description text for the typedefs make an
explicit reference to the IANA registry for these number spaces?

* BFD types YANG Module

  - The statement "This module contains a collection of BFD specific
YANG data type definitions" seems wrong since you define way more
things that just datatypes. In fact, ietf-bfd-types is kind of a
misnomer; perhaps this should be ietf-bfd-common (the -common was
used in RFC 8194 but I am biased here).

  - s/Two interval values or 1 value/Two interval values or one value/

  - I think this is unclear (for me):

  leaf down-count {
 type uint32;
 description "Session Down Count.";
   }