Hi Dan,
Sorry about the slow response.
On 1/25/2018 11:47 AM, Dan Romascanu wrote:
Reviewer: Dan Romascanu
Review result: Has Issues
This is a very useful, well thought and well written document, which reflects
work and discussions within the RTG and OPS areas. From an operational point of
view it's a very useful tool in support of network operators that will manage
and configure logical elements. I believe that the document is almost ready,
but there are a number of issues that are worth being discussed and addressed
before approval by the IESG.
1. The name and scope of the document as presented in the title and Abstract
are not exactly reflecting the content. LNEs are not YANG LNEs as the title
says, and the type of module (a YANG module) being defined is not stated in the
Abstract.
This is fixed in -06.
I would suggest that the document actually defines 'A Data Model and
YANG Module for Logical Network Elements'.
okay, changed to 'YANG Module for Logical Network Elements'.
2. There is no reference and relationship definition in the document to the
YANG Data Model for Hardware Management defined in
https://tools.ietf.org/html/draft-ietf-netmod-entity-07. Actually the LNEs are
almost similar with the 'logical entities' that were dropped from the
netmod-entity work. It is expected that in the future network operators will
use both data models and the respective YANG modules when managing hardware
devices on which logical network entities are being run. Even if this
relationship is not explicitly present in the DM, I believe that it needs to be
looked at and mentioned in the document.
okay, it's been added to the example section as a possible model to be
mounted.
3. In Section 2 I see:
'The logical-network-element module augments existing
interface management model by adding an identifier which is used on
physical interface types to identify an associated LNE.'
I am wondering why the mentioning of 'physical interface types' here. What if
the interface type in not 'physical' representing a protocol layer or sublayer
on the device? After all, if all interfaces to be considered were 'physical' we
could have augmented the entity hardware module rather than the interfaces
module, as all physical interfaces are represented there as well.
excellent catch! it should just say interfaces, it's up to an
implementation to choose which can be bound to an LNE.
4. Sections 3.2 and 3.3 seem to be written for the benefit and the perspective
of the implementations writers rather than of the operators. Are there any
hints, advice, or indications for the operators using the module to manage
their LNEs? These could be described also in the examples appendices, which are
otherwise very useful to illustrate and explain the models.
I reread these sections as well as the examples and the read to me to be
almost completely applicable/useful to both client and server - so am at
a bit of a loss on how best to address this comment. Perhaps I'm just
too close to the material. Can you provide a specific example of the
type of improvement you'd like to see?
Thank you for the comments!
Lou
_______________________________________________
rtgwg mailing list
rtgwg@xxxxxxxx
https://www.ietf.org/mailman/listinfo/rtgwg
