Re: [Lsr] I-D Action: draft-ietf-isis-yang-isis-cfg-35.txt

[tom petch <[e-mail]>]

<inline>

---- Original Message -----
From: <[e-mail]>
Sent: Friday, June 07, 2019 9:03 AM

Hi Tom,

Thanks for your feedback.
Pls find some comments inline

Stephane

-----Original Message-----
From: tom petch [mailto:[e-mail]]
Sent: Thursday, June 06, 2019 18:59

Stephane

The YANG module has RFC5307 in a description clause but I do not see
this in the References of the I-D

[SLI] That's a mistake, I will fix it


I commented before on the lack of  a conditional when on
     augment "/if:interfaces/if:interface"
so every interface will get this object; is that intended?

[SLI] It looks good to me, if a device supports the ISIS model, all the
interfaces should get the clns-mtu config statement.

<tp>

Well, yes, the server will understand what the definition is but a user
might be surprised to find the object present on an ospf passive
interface or a LAN interface running RIP - I do not see that as a big
problem but thought I would ask.

In the example, is the system-id one reserved for documentation?
[SLI] No, but I'm personally not aware of system IDs reserved for
documentation as we could have for IP addresses. If someone from the WG
knows about it, I will be happy to change it.

<tp>
I did look and there are identifiers reserved for documenation for all
sorts of things but not AFAICT for system-id; I wondered if there was
any convention in the ISO documents.  I am twitchy about using
potentially real identifiers in documentation ever since I encountered
an organisation which had to renumber everything because the engineer
who had set up the organisation's network had been on a course to learn
how to do it, the course has used real addresses and the engineer had
then used these real addresses for his organisation's network thinking
that that was what everyone had to do - oh dear.

Tom Petch

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, March 08, 2019 3:37 AM
Subject: I-D Action: draft-ietf-isis-yang-isis-cfg-35.txt


>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Link State Routing WG of the IETF.
>
>         Title           : YANG Data Model for IS-IS Protocol
>         Authors         : Stephane Litkowski
>                           Derek Yeung
>                           Acee Lindem
>                           Jeffrey Zhang
>                           Ladislav Lhotka
> Filename        : draft-ietf-isis-yang-isis-cfg-35.txt
> Pages           : 111
> Date            : 2019-03-07
>
> Abstract:
>    This document defines a YANG data model that can be used to
configure
>    and manage IS-IS protocol on network elements.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35
> https://datatracker.ietf.org/doc/html/draft-ietf-isis-yang-isis-cfg-35
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-yang-isis-cfg-35
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


________________________________________________________________________
_________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.