Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15

[Mahesh Jethanandani]

Hi Jürgen,

It appears that Brian and you had made progress on the other thread related to 
IPv6 zone definition. Are there any outstanding issues that need to be resolved?

What is the plan to submit an updated version of the document?

Thanks.

> On Apr 5, 2024, at 11:23 PM, Jürgen Schönwälder 
>  wrote:
> 
> Hi Mahesh,
> 
> I stopped working on this document since the AD indicated that he will
> refuse any non-backwards compatible changes (regardless whether they
> can be considered bug fixes). And I am personally also not happy about
> some of the new naming conventions (which this message/thread was
> about). If we are now taking a fresh look at things, I can produce a
> new version, but this really only makes sense if we are willing to
> actually publish this update.
> 
> /js
> 
> On 06.04.24 06:04, Mahesh Jethanandani wrote:
>> Hi Juergen,
>> Reviving this thread to identify next steps for the document. Where are we 
>> with publishing a -16 version of the draft?
>> I do not see objections to most of your suggestions on the changes you 
>> recommend. For milli vs micro part of the discussion, could we have both?
>> Separately, on the other thread on for changes to IPv6 zone definition, 
>> which I will respond to, can you summarize what the consensus is, so we can 
>> try to close on the thread.
>> Thanks
>>> On Mar 23, 2023, at 11:29 AM, Andy Bierman  wrote:
>>> 
>>> 
>>> 
>>> On Thu, Mar 23, 2023 at 5:11 AM tom petch >> <mailto:ie...@btconnect.com>> wrote:
>>> From: netmod mailto:netmod-boun...@ietf.org>> on 
>>> behalf of Jürgen Schönwälder 
>>> Sent: 23 March 2023 11:13
>>> 
>>> On Wed, Mar 22, 2023 at 01:31:43PM +, Rob Wilton (rwilton) wrote:
>>>> Hi Jürgen,
>>>> 
>>>> Thanks for the draft.  Please see my AD review comments below, except for 
>>>> a couple of comments related to the change to ipv6-address definition that 
>>>> I've spun into a separate thread so that I can include the interested 
>>>> parties of draft-ietf-6man-rfc6874bis into the discussion.
>>> 
>>> Thanks for your review. See responses inline.
>>> 
>>>> Moderate level comments:
>>>> 
>>>> (1) p 13, sec 3.  Core YANG Types
>>>> 
>>>>  typedef date-with-zone-offset {
>>>> 
>>>> Why don't we just call this 'date' rather than 'date-with-zone-offset', 
>>>> particularly because the zone information is optional?  Intuitively, from 
>>>> the name of this type, I would have expected that zone information as 
>>>> being required rather than being optional.
>>>> 
>>>> I also note that the current naming convention of this type seems somewhat 
>>>> inconsistent from "date-no-zone", since one of them includes "offset" and 
>>>> the other does not.
>>>> 
>>>> This same comment also applies to 'time-with-zone-offset'.
>>> 
>>> Earlier versions had just 'date' and 'time' and both included a zone
>>> offset. We then also got 'date-no-zone' and 'time-no-zone' and all was
>>> kind of nice and consistent. Then the IP address debate kicked in and
>>> finally some people made the point that we should be always explicit
>>> (but then you can't encode all semantics in a name anyway). So this is
>>> how we got to the names we have now. For me personally, 'date' and
>>> 'date-no-zone' and 'time' and 'time-no-zone' was just fine. The
>>> '-offset' came in as a way to future proof definitions since in some
>>> contexts you may want to indicate the timezone not with a fixed offset
>>> but with a timezone name like 'Europe/Berlin' that is then resolved
>>> using more complex rules to a specific offset.
>>> 
>>> I personally would be happy to change date-with-zone-offset back to
>>> date and time-with-zone-offset back to time and to deal with the
>>> future in the future...
>>> 
>>> 
>>> 
>>> Me too.  I think that the fashion for incorporating ever more semantics 
>>> into an identifier is a misunderstanding of what an identifier is for ie to 
>>> identify.
>>> 
>>> 
>>> Me three.
>>> IMO simple names like 'date' and 'time' and 'date-and-time' are easier to 
>>> understand.
>>> Optional fields are different than mandatory fields.
>>> If a data type has some mandatory field, then it may need to have its own 
>>> typedef and name.
>>> 
&

Re: [netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15

[Mahesh Jethanandani]

/" which is troublesome in URIs.
>> Maybe you could consider an even more complex definition that distinguishes 
>> general zone identifiers from URI-friendly zone identifiers? The latter 
>> would be something like
>> '(%[a-z0-9][a-z0-9\-\._~]*)?'
>> Then there could be a general recommendation to use the restricted character 
>> set if, and only if, there is an operational requirement to generate URIs 
>> for a given interface.
>>>  draft-ietf-6man-rfc6874bis, which I'm currently holding a 'discuss' ballot 
>>> position on, effectively limits the usable character set of zone-ids to the 
>>> unreserved set in URIs, which seems to match those above except for '/' 
>>> that is allowed above (and used in many interface names), but not in the 
>>> URI's unreserved character set.  A further difference is that upper case 
>>> characters are allowed in this typedef but are not allowed when used in the 
>>> host part of URIs.
>> Well, more precisely they will almost certainly be normalized to lower case 
>> by the URI parser.
>>   
>>> Update - I've now seen the thread 'ipv6-address in RFC 6991 (and bis)', and 
>>> Jürgen has put together a useful blog post, thanks!
>>> 
>>> Given that "interface-name" in RFC 8343, and the text in RFC 4007 section 
>>> 11.2, then arguably the safest thing here would be to allow the zone-id to 
>>> be unrestricted, i.e., "(%.*)?"  However, this would leave 
>>> draft-ietf-6man-rfc6874bis as only being able to support a small fraction 
>>> of interface names as zone-ids in URLs.  The authors of 
>>> draft-ietf-6man-rfc6874bis seem to indicate that it works for all interface 
>>> names that currently matter for their use case.
>> That appears to be correct, as noted in the newly proposed text at
>> https://www.cs.auckland.ac.nz/~brian/draft-ietf-6man-rfc6874bis-06X.html#section-1-5
>>> 
>>> An alternative solution could be to somewhere define the zone-ids in YANG 
>>> to match the restrictive set in draft-ietf-6man-rfc6874bis (i.e., lower 
>>> case only, and disallow '/').  I think that this would then require that we 
>>> recommend a conversion of interface names into draft-ietf-6man-rfc6874bis 
>>> compatible zone-ids interface-names.  E.g., such a conversion could take 
>>> the interface name, and change any uppercase characters to lower case, and 
>>> replace any symbol that isn't in the allowed character set with '_'.  This 
>>> conversion is effectively one way, and there is a theoretical risk that the 
>>> converted interface names could collide, but this may be unlikely in 
>>> practice.  Obviously, this conversation doesn't handle non-ASCII interface 
>>> names, but I'm not sure how realistic it is that they would be used anyway.
>> Remember there is a browser between the URI and the operating system, and 
>> the browser communicates with the operating system via a socket interface. 
>> So such a conversion is useless unless the socket interface in the device 
>> concerned is fully aware of the mapping. So even if there is a use case, 
>> there are a lot of moving parts here.
>> Personally I think allowing non-ASCII would be disastrously complex and 
>> would have no real advantage for netops staff. Езернет1/0/1 instead of 
>> Ethernet1/0/1 doesn't seem worth all the resultant hassle.
>>> 
>>> This general comment also applies for the same change for 'ipv4-address'.
>> Fortunately this is 100% out of scope for the 6man draft.
>>> 
>>> (3) draft-ietf-netmod-rfc6991-bis-15, p 28, sec 4.  Internet Protocol Suite 
>>> Types
>>> 
>>>   The canonical format of IPv6 addresses uses the textual
>>>   representation defined in Section 4 of RFC 5952.  The
>>>   canonical format for the zone index is the numerical
>>>   format as described in Section 11.2 of RFC 4007.";
>>> 
>>> Would it make sense to also change the canonical format for the zone index 
>>> to be interface name (or converted interface name) rather than numeric id 
>>> (when used in YANG models)?
>> Please not. In a completely different context (RFC 8990) I've written code 
>> handling link local addresses and multiple interfaces, and driving it by 
>> interface index rather than by name is definitely the way to go. Humans may 
>> like the names, but the numbers are much better for programs.
>> Regard
>> Brian
>>> 
>>> This comment also applies for the same change for 'ipv4-address'.
>>> 
>>> 
>>> Thoughts and comments on these two issues are welcome.
>>> 
>>> Regards,
>>> Rob
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15

[Mahesh Jethanandani]

t; > (5) p 14, sec 3.  Core YANG Types
> >
> >type date-with-zone-offset {
> >  pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])';
> >}
> >
> > Although I can understand why it is modelled this way, i.e., to make the 
> > relationship between the types clear, there is likely to be a small 
> > performance overhead of modelling it this way, where this regex for this 
> > type is a strict subset of date-with-zone-offset.  I wonder whether it 
> > would be cleaner to just define this type as an equivalent top-level type 
> > to date-with-zone-offset, both in the definition and description rather 
> > than as a derived type?
> >
> > This same comment also applies to 'time-no-zone'.
> 
> This would require to copy quite some text and then this cloned text
> needs to be kept consistent in the future. I do not think this is a
> good idea. Implementations can take shortcuts if this is found to be
> time critical (but that might also be very implementation specific).
> My preference is to not change this.
> 
> > (6) p 15, sec 3.  Core YANG Types
> >
> >  The maximum time period that can be expressed is in the
> >  range [-89478485 days 08:00:00 to 89478485 days 07:00:00].
> >
> > I found this notation slightly confusing.  When I originally saw it, I 
> > assumed that it is talking about time zones, and it only really made sense 
> > when comparing it to the other periods.
> >
> > I wasn't sure whether the specific details are that important, and whether 
> > defining it as -89478485 days to 89478485 days, might be both sufficient 
> > and easier to read.
> >
> > E.g.,
> >  The maximum time period that can be expressed is in the
> >  range [-89478485to 89478485] days .
> >
> > If changed, this same comment applies to the other period types as well.
> 
> For time periods with lower resolution, the details start to matter,
> (see microseconds32 on the extreme end) and so I ended up using the
> same notation and precision for all types. I think this is generally
> the right thing to do, being always precise is better than arbitrarily
> dropping precision. If someone has ideas for a better notation, I am
> open for that. Perhaps adding ", where hh:mm:ss stands for hours,
> minutes and seconds" would already do it?:
> 
>  The maximum time period that can be expressed is in the
>  range [-89478485 days 08:00:00 to 89478485 days 07:00:00],
>  where hh:mm:ss stands for hours, minutes and seconds."
> 
> > (7) p 15, sec 3.  Core YANG Types
> >
> >  This type should be range restricted in situations
> >  where only non-negative time periods are desirable,
> >  (i.e., range '0..max').";
> >
> > Isn't this going to be the common mainline case for network configuration?  
> > I.e., I presume that most cases where periods are intervals are going to be 
> > reported will be positive.  Hence, it might be helpful to have a separate 
> > set of types defined for the positive only cases.
> >
> > This same comment applies to the other period types.
> 
> I ones had unsigned versions of these types. If we also add unsigned
> types, we end up with nine additional types, we would get something
> like:
> 
> hours-int32
> hours-uint32
> minutes-int32
> minutes-uint32
> seconds-int32
> seconds-uint32
> ...
> nanoseconds-int64
> nanoseconds-uint64
> 
> Well, perhaps this is the right thing to do, people can then pick what
> is most appropriate for their use case.
> 
> > (8) p 16, sec 3.  Core YANG Types
> >
> >  typedef milliseconds32 {
> >
> > I was slightly surprised that we don't have a milliseconds64, e.g., the 
> > default timestamp in Java is given as an int64 in milliseconds.
> >
> 
> So far nobody asked for it. On POSIX systems (I think POSIX.1-2001 and
> later), you usually have system APIs that can go into microsecond
> resolution:
> 
>struct timeval {
>time_t  tv_sec; /* seconds */
>suseconds_t tv_usec;/* microseconds */
>};
> 
> But if there is a use case for milliseconds64, I can easily add it.
> well milliseconds-int64 and milliseconds-uint64, depending on the
> resolution of your previous point.
> 
> > Nit level comments:
> >
> > (9) p 21, sec 3.  Core YANG Types
> >
> >   7950. An earlier version of this definition did exclude
> >
> > I suggest 'did exclude' -> 'excluded'
> 
> Changed.
> 
> /js
> 
> --
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://constructor.university/ 
> <https://constructor.university/>>
> 
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
> 
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>

Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

[Mahesh Jethanandani]

Hi Joe,Your name popped up on this thread. See below. Mahesh Jethanandani mjethanand...@gmail.comOn Feb 8, 2024, at 4:01 AM, mohamed.boucad...@orange.com wrote:







Hi Mahesh, all,

 
FWIW, we submitted an updated version of the draft to address the pending points from your reviews. A diff to track the changes vs. -04 can be seen at:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-netmod-acl-extensions-04=draft-ietf-netmod-acl-extensions-06=--html.
 
Cheers,
Med
 



De : BOUCADAIR Mohamed INNOV/NET 
Envoyé : mardi 23 janvier 2024 16:57
À : 'Mahesh Jethanandani' 
Cc : Lou Berger ; NETMOD Group ; NetMod WG Chairs 
Objet : RE: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03


 
Hi Mahesh,

 
Thanks for the follow-up. Made some changes as you can see at

https://boucadair.github.io/enhanced-acl-netmod/#go.draft-ietf-netmod-acl-extensions.diff.
 
Please see inline for more context.

 
Cheers,
Med
 
 

Orange Restricted



De : Mahesh Jethanandani <mjethanand...@gmail.com>

Envoyé : mercredi 20 décembre 2023 18:20
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
Cc : Lou Berger <lber...@labn.net>; NETMOD Group <netmod@ietf.org>; NetMod WG Chairs <netmod-cha...@ietf.org>
Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03


 
Hi Med,

 


Thanks for addressing some of my comments. Please see inline.

 


On Dec 19, 2023, at 12:09 AM, 
mohamed.boucad...@orange.com wrote:

 


Hi Mahesh, all,


 


Thank you for the review and comments. We just posed draft-ietf-netmod-acl-extensions-04.


 


Please see more context inline.


 


Cheers,


Med


 





De : netmod <netmod-boun...@ietf.org> De la part de Mahesh
 Jethanandani
Envoyé : mardi 5 décembre 2023 23:09
À : Lou Berger <lber...@labn.net>
Cc : NETMOD Group <netmod@ietf.org>; NetMod WG Chairs <netmod-cha...@ietf.org>
Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03




 


Hi,



 




I do support this work, as it is much needed, and would like to see it progress. However, I do believe that the document needs to undergo a revision to qualify for LC. Some of the comments are editorial or minor, and can be addressed easily,
 but others are not. They should all be addressed for the WG to call the document ready.



 




- The Security Considerations section has both the read/write nodes and the read-only nodes as empty (or marked as TBC, which I imagine stands for To Be Completed). This needs to be filled out, or if no nodes are worth any security considerations,
 it should be stated so, and why.


 


[Med] ACK. We don’t repeat what is already in 8519 but focus on key additions in the spec: https://github.com/boucadair/enhanced-acl-netmod/pull/65/files







 

[mj] Thanks for updating the section. 


 


s/setf/set/


s/Simialr/Similar/


 


and in other place


s/modelled/modeled/


 
[Med] Thanks. Fixed.
 






 




- Isn’t the YANG model normative portion of the document? Isn’t what this document all about? Why is it then in the Appendix?


 


[Med] We are using a script to generate the IANA modules + we are actually following this part from the 8407bis:


 


   It is RECOMMENDED to include the URL from where to retrieve the


   recent version of the module.  When a script is used, the Internet-


   Draft that defines an IANA-maintained module SHOULD include an


   appendix with the initial full version of the module.  Including such


   an appendix in pre-RFC versions is meant to assess the correctness of


   the outcome of the supplied script.  The authors MUST include a note


   to the RFC Editor requesting that the appendix be removed before


   publication as RFC and that RFC  is replaced with the RFC number


   that is assigned to the document.  Initial versions of IANA-


   maintained modules that are published in RFCs may be misused despite


   the appropriate language to refer to the IANA registry to retrieve


   the up-to-date module.







 

[mj] I am not clear on what happens to the IANA module once the draft is published as an RFC based on what you cite from 8407bis.
[Med] It will be removed as per the note:

 
(2) The modules are provided in {{iana-icmp}}, {{iana-icmpv6}}, and {{iana-ipv6-ext}} for the users convenience before publication as RFC. Please remove these appendices from the
 final RFC.
 
The document states that the reference to “RFC ” is replaced with the actual RFC number, but  it also says that the Appendix be removed.
What happens to the initial version of the module itself? Is it removed if the Appendix is removed?

[Med] It will be removed as per the note above. Please note that this practice is already followed in rfc9108, for example.
 
Or does it remain in the Appendix as an initial version, with language that indicates that the IANA registry should be used to retrieve the most up-to-date model?
The language in Section 1.1 item (2) does not help.


 


The above 

Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Mahesh Jethanandani]

Hi Med,

Thanks for driving this effort on updating RFC 8407. 

One additional change coming your way, is to address the question of how IANA 
is supposed to handle updates to IANA YANG modules. The YANG doctors are 
currently debating those changes. Once agreed, we will bring that discussion 
here, and will need to update rfc8407bis to provide guidance to authors who 
update an IANA module. Stay tuned.

Cheers.

> On Mar 12, 2024, at 5:00 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi all, 
>  
> A candidate -10 is ready to address 3 comments from Jan:
> Long trees
> Updated security template
> Minor tweaks to Section 3.8
> The changes circulated on the list can be seen here: Compare Editor's Copy to 
> Datatracker 
> <https://boucadair.github.io/rfc8407bis/#go.draft-ietf-netmod-rfc8407bis.diff>
> Jan raised two other comments (short/uniqueness of prefixes + how to handle 
> “not set”) but no changes were made per the feedback received on the list.  
> Next steps:
> Submit -10 right after IETF#119
> WGLC
>  
> Cheers,
> Med
> 
> 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.
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>

Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] Deviating in circles

[Mahesh Jethanandani]

Hi Jan,

See inline

> On Mar 4, 2024, at 11:26 AM, Jan Lindblad (jlindbla) 
>  wrote:
> 
> Reshad,
> 
>> Does the same question arise with augments?
> 
> No, I don't think so. Augments cannot modify existing namespaces, only add 
> content in their own namespace, then graft that namespace onto some existing 
> module. If that existing module imports the augmenting module, I would 
> imagine all YANG compilers would catch the attempt to create an import loop.
> 
>> Inline.
> ...
>> Is the construct in module d legal? RFC 7950 is not very clear on the 
>> subject, but it does say:
>> 
>>After applying all deviations announced by a server, in any order,
>>the resulting data model MUST still be valid.
>> 
>> If "applying" means actually replacing the original module text with the 
>> deviated text, then I'm fairly sure module d would violate the rule against 
>> circular imports. If "applying" is something that happens on a more "global" 
>> or "logical" level, then maybe this should be allowed?
>> 
>>  I don't know what was the intention of the 7950 authors and not even 
>> sure what would be the "right thing". My guess would be it's more in the 
>> "logical" level.
>> 
>> By allowing deviations of this kind, we might create a temptation for people 
>> to use deviations for their own modules in order to create YANG structures 
>> otherwise not possible. I find this problematic, since I don't like 
>> deviations much. On the other hand, allowing deviations of this kind 
>> increases the freedom of expression in the YANG world. I think many would 
>> regard a moratorium as another YANG CLR (crappy little rule).
>> 
>> If we were to decide that this sort of deviation is allowed, wouldn't a 
>> logical conclusion be that we should drop the circular imports rule? 
>> Compilers could very well track which modules have already been imported 
>> (like in python), and not go into unbounded spin just because there is a 
>> circular reference loop.
>> 
>>  yang-next?
> 
> We could of course clarify this or change the rules in yang-next once we know 
> what we want (I'm split on this one), but I was interested in the opinion of 
> the list whether this is allowed today.
> 

Please continue to have the discussion here, but suggest you create a new issue 
here <https://github.com/netmod-wg/yang-next/issues>, so the issue can be 
tracked.

Cheers.


> Best Regards,
> /jan
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] Long trees RE: Next steps for draft-ietf-netmod-rfc8407bis

[Mahesh Jethanandani]

___
> 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.
> 
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
>  
> 
> 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.
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>

Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints (fix draft address)

[Mahesh Jethanandani]

 what can be represented, so it is a judgement call.)
> > 
> > /js
> > 
> > -- 
> > Jürgen Schönwälder  Constructor University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 <https://constructor.university/ 
> > <https://constructor.university/>>
> 
> ___
> yang-doctors mailing list
> yang-doct...@ietf.org <mailto:yang-doct...@ietf.org>
> https://www.ietf.org/mailman/listinfo/yang-doctors 
> <https://www.ietf.org/mailman/listinfo/yang-doctors>
> 
> 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.
> ___
> yang-doctors mailing list
> yang-doct...@ietf.org <mailto:yang-doct...@ietf.org>
> https://www.ietf.org/mailman/listinfo/yang-doctors 
> <https://www.ietf.org/mailman/listinfo/yang-doctors>

Mahesh Jethanandani
mjethanand...@gmail.com






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

[netmod] Yangdoctors early review of draft-ietf-netmod-acl-extensions-04

[Mahesh Jethanandani via Datatracker]

Reviewer: Mahesh Jethanandani
Review result: Almost Ready

I had started providing my review comments before I was assigned to (formally)
review the document. I will therefore (re)use that thread here. And in order to
understand the level of quotation, I have added either >>, a >, or nothing to
indicate the level.



>> I do support this work, as it is much needed, and would like to see it
progress. However, I do believe that the document needs to undergo a revision
to qualify for LC. Some of the comments are editorial or minor, and can be
addressed easily, but others are not. They should all be addressed for the WG
to call the document ready.

>> - The Security Considerations section has both the read/write nodes and the
read-only nodes as empty (or marked as TBC, which I imagine stands for To Be
Completed). This needs to be filled out, or if no nodes are worth any security
considerations, it should be stated so, and why.

> [Med] ACK. We don’t repeat what is already in 8519 but focus on key additions
in the spec: https://github.com/boucadair/enhanced-acl-netmod/pull/65/files

[mj] Thanks for updating the section.

s/setf/set/
s/Simialr/Similar/

and in other place
s/modelled/modeled/

>> - Isn’t the YANG model normative portion of the document? Isn’t what this
document all about? Why is it then in the Appendix?

> [Med] We are using a script to generate the IANA modules + we are actually
following this part from the 8407bis:

>   It is RECOMMENDED to include the URL from where to retrieve the
   recent version of the module.  When a script is used, the Internet-
   Draft that defines an IANA-maintained module SHOULD include an
   appendix with the initial full version of the module.  Including such
   an appendix in pre-RFC versions is meant to assess the correctness of
   the outcome of the supplied script.  The authors MUST include a note
   to the RFC Editor requesting that the appendix be removed before
   publication as RFC and that RFC  is replaced with the RFC number
   that is assigned to the document.  Initial versions of IANA-
   maintained modules that are published in RFCs may be misused despite
   the appropriate language to refer to the IANA registry to retrieve
   the up-to-date module.

[mj] I am not clear on what happens to the IANA module once the draft is
published as an RFC based on what you cite from 8407bis. The document states
that the reference to “RFC ” is replaced with the actual RFC number, but 
it also says that the Appendix be removed. What happens to the initial version
of the module itself? Is it removed if the Appendix is removed? Or does it
remain in the Appendix as an initial version, with language that indicates that
the IANA registry should be used to retrieve the most up-to-date model? The
language in Section 1.1 item (2) does not help.

The above text from 8407bis needs to be explicit on what happens to the initial
version of the module as part of the RFC publication.

>> - Why is the Section titled "Initial Version of the The ICMPv4 Types
IANA-Maintained Module”, when the model in question is
"iana-icmpv6-ty...@2020-09-25.yang”? > [Med] This was a typo. Fixed.

[mj] You fixed it another location. However, I still see the following in the
-04 version of the document.

B.2. Initial Version of the The ICMPv4 Types IANA-Maintained Module

 file "iana-icmpv6-ty...@2020-09-25.yang"

module iana-icmpv6-types {

>> - ‘defined-sets’ and ‘aliases’ have been defined in a the separate model
‘ietf-acl-enh’. Are these sets and aliases defined to be used outside of ACL?
If that is the case then having them outside the ‘ietf-access-control-list’
model makes sense. Otherwise, almost everything in the ‘ietf-acl-enh’ is an
augmentation of the model defined in RFC 8519, as stated in the Introduction of
the document

> [Med] These are defined to be consumed for ACL policies.

>> "The YANG module in this document is solely based on augmentations to the
ACL YANG module defined in [RFC8519].”

> [Med] The intent was to highlight that we are not using a bis approach.
Tweaked the paragraph that includes that text for better clarity.

[mj] I think it already clear that this model an augmentation and not a bis. A
bis is when you take the original document and edit it for updates, and this is
clearly not that.

I actually agree with your above statement in the Introduction that you had,
about the module being solely an enhancement of the ACL YANG model, and was
surprised to see it taken out. The point I was making was that just like what
you have done with augmenting "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches”
to add ‘choice payload’, ‘choice alias’ etc, you could have augmented
“/acl:acls” to add ‘defined-sets’ and ‘aliases’. Right now, as is, the
ietf-acl-enh module sits on the root of the config tree, with no relation to
the ACL mod

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

[Mahesh Jethanandani]

Hi Med,

Thanks for addressing some of my comments. Please see inline.

> On Dec 19, 2023, at 12:09 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Mahesh, all,
>  
> Thank you for the review and comments. We just posed 
> draft-ietf-netmod-acl-extensions-04.
>  
> Please see more context inline.
>  
> Cheers,
> Med
>  
> De : netmod mailto:netmod-boun...@ietf.org>> De la 
> part de Mahesh Jethanandani
> Envoyé : mardi 5 décembre 2023 23:09
> À : Lou Berger mailto:lber...@labn.net>>
> Cc : NETMOD Group mailto:netmod@ietf.org>>; NetMod WG 
> Chairs mailto:netmod-cha...@ietf.org>>
> Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03
>  
> Hi,
>  
> I do support this work, as it is much needed, and would like to see it 
> progress. However, I do believe that the document needs to undergo a revision 
> to qualify for LC. Some of the comments are editorial or minor, and can be 
> addressed easily, but others are not. They should all be addressed for the WG 
> to call the document ready.
>  
> - The Security Considerations section has both the read/write nodes and the 
> read-only nodes as empty (or marked as TBC, which I imagine stands for To Be 
> Completed). This needs to be filled out, or if no nodes are worth any 
> security considerations, it should be stated so, and why.
>  
> [Med] ACK. We don’t repeat what is already in 8519 but focus on key additions 
> in the spec: https://github.com/boucadair/enhanced-acl-netmod/pull/65/files 
> <https://github.com/boucadair/enhanced-acl-netmod/pull/65/files>
[mj] Thanks for updating the section. 

s/setf/set/
s/Simialr/Similar/

and in other place
s/modelled/modeled/

>  
> - Isn’t the YANG model normative portion of the document? Isn’t what this 
> document all about? Why is it then in the Appendix?
>  
> [Med] We are using a script to generate the IANA modules + we are actually 
> following this part from the 8407bis:
>  
>It is RECOMMENDED to include the URL from where to retrieve the
>recent version of the module.  When a script is used, the Internet-
>Draft that defines an IANA-maintained module SHOULD include an
>appendix with the initial full version of the module.  Including such
>an appendix in pre-RFC versions is meant to assess the correctness of
>the outcome of the supplied script.  The authors MUST include a note
>to the RFC Editor requesting that the appendix be removed before
>publication as RFC and that RFC  is replaced with the RFC number
>that is assigned to the document.  Initial versions of IANA-
>maintained modules that are published in RFCs may be misused despite
>the appropriate language to refer to the IANA registry to retrieve
>the up-to-date module.

[mj] I am not clear on what happens to the IANA module once the draft is 
published as an RFC based on what you cite from 8407bis. The document states 
that the reference to “RFC ” is replaced with the actual RFC number, but  
it also says that the Appendix be removed. What happens to the initial version 
of the module itself? Is it removed if the Appendix is removed? Or does it 
remain in the Appendix as an initial version, with language that indicates that 
the IANA registry should be used to retrieve the most up-to-date model? The 
language in Section 1.1 item (2) does not help.

The above text from 8407bis needs to be explicit on what happens to the initial 
version of the module as part of the RFC publication.

>  
> - Why is the Section titled "Initial Version of the The ICMPv4 Types 
> IANA-Maintained Module”, when the model in question is 
> "iana-icmpv6-ty...@2020-09-25.yang 
> <mailto:iana-icmpv6-ty...@2020-09-25.yang>”?
> [Med] This was a typo. Fixed.

[mj] You fixed it another location. However, I still see the following in the 
-04 version of the document.

B.2. Initial Version of the The ICMPv4 Types IANA-Maintained Module

 file "iana-icmpv6-ty...@2020-09-25.yang"


module iana-icmpv6-types {

>  
> - ‘defined-sets’ and ‘aliases’ have been defined in a the separate model 
> ‘ietf-acl-enh’. Are these sets and aliases defined to be used outside of ACL? 
> If that is the case then having them outside the ‘ietf-access-control-list’ 
> model makes sense. Otherwise, almost everything in the ‘ietf-acl-enh’ is an 
> augmentation of the model defined in RFC 8519, as stated in the Introduction 
> of the document
>  
> [Med] These are defined to be consumed for ACL policies.

>  
>  
> "The YANG module in this document is solely based on augmentations to the ACL 
> YANG module defined in [RFC8519].”
>  
> [Med] The intent was to highlight that we are not using a bis approach. 
> Tweaked the paragraph that includes that text for

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

[Mahesh Jethanandani]

Hi,

I do support this work, as it is much needed, and would like to see it 
progress. However, I do believe that the document needs to undergo a revision 
to qualify for LC. Some of the comments are editorial or minor, and can be 
addressed easily, but others are not. They should all be addressed for the WG 
to call the document ready.

- The Security Considerations section has both the read/write nodes and the 
read-only nodes as empty (or marked as TBC, which I imagine stands for To Be 
Completed). This needs to be filled out, or if no nodes are worth any security 
considerations, it should be stated so, and why.

- Isn’t the YANG model normative portion of the document? Isn’t what this 
document all about? Why is it then in the Appendix?

- Why is the Section titled "Initial Version of the The ICMPv4 Types 
IANA-Maintained Module”, when the model in question is 
"iana-icmpv6-ty...@2020-09-25.yang”?

- ‘defined-sets’ and ‘aliases’ have been defined in a the separate model 
‘ietf-acl-enh’. Are these sets and aliases defined to be used outside of ACL? 
If that is the case then having them outside the ‘ietf-access-control-list’ 
model makes sense. Otherwise, almost everything in the ‘ietf-acl-enh’ is an 
augmentation of the model defined in RFC 8519, as stated in the Introduction of 
the document

"The YANG module in this document is solely based on augmentations to the ACL 
YANG module defined in [RFC8519].”

If that is the case I see no reason why those containers should not be 
augmentations into the same model, as in

augment “/acl” {
  container defined-sets {
  ….
  }

  container aliases {
 …
  }
}
  

- I just pulled down the latest version (-03) of the draft, and ran into this 
error. 

$ pyang ietf-acl-...@2022-10-24.yang 
iana-icmpv6-ty...@2020-09-25.yang:1: error: unexpected latest revision 
"2023-04-28" in iana-icmpv6-ty...@2020-09-25.yang, should be "2020-09-25”.

- Section 3.4. TCP Flags Handling. The document states that. 

"Clients that support both 'flags-bitmask' and 'flags' matching fields MUST NOT 
set these fields in the same request.”.

Can the model have a must statement to prevent this from being configured 
inadvertently?

Same for Section 3.5 Fragments Handling

- There should be clear direction to the RFC Editor on what should be done with 
revision dates. The same is true for other placeholder text. For example, what 
is the RFC Editor to do with text "RFC "?

- References in the YANG model should be expanded to include the title of the 
RFC.

- Examples are always good. Not only can they be used to validate the model, 
but users get to understand how it can be used. See other models such as BGP, 
TCP, BFD on how an example can be added.

- How is this a reference?
reference
  "- Bill Simpson <mailto:Bill.Simpson>


Thanks.


> On Dec 4, 2023, at 3:00 PM, Lou Berger  wrote:
> 
> All,
> 
> This starts working group last call on
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/
> 
> The working group last call ends on December 18th (any TZ).
> Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> Lou (Co-Chair & doc Shepherd)
> 
> _______
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] IANA YANG Parameters repository

[Mahesh Jethanandani]

iana-iss...@iana.org <mailto:iana-iss...@iana.org>

The issue is specific to line 191 and 213 of the module.

> On Nov 15, 2023, at 7:05 AM, Jernej Tuljak  wrote:
> 
> Hi,
> 
> I detected a syntactically invalid YANG file among those available at 
> "https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml;.
> 
> Does anyone know how to report this to them? Is 
> "https://www.iana.org/form/complaint; an appropriate channel for something 
> like this?
> 
> The actual file is 
> "https://www.iana.org/assignments/yang-parameters/ietf-te-topology-st...@2020-08-06.yang;.
>  Whatever extracted it from the RFC mishandled '<' and '>' characters and 
> replaced them with XML character entity references, including some inside 
> XPath expressions.
> 
> Jernej
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






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

[netmod] ACL Extensions Draft

[Mahesh Jethanandani]

The question in the WG for the ACL Extensions draft was whether the draft 
should be an augmentation of the base ACL model, or a -bis of RFC 8519. Lou 
brought some clarity by saying that if the base model could exist by itself 
without these extensions, then it should be treated as an augmentation, but if 
there are fundamental additions to the base model that should have existed from 
day 1, it should be a -bis.

Looking at the changes being proposed by the draft, I see a combination of 
extensions, e.g. defined-sets, and changes that are fairly fundamental to the 
usage of ACL model. I am sorry that we missed them in RFC 8519. Examples of 
that include definitions for ipv4-fragment, ipv6-fragment, mpls etc. It is for 
those fundamental definitions, my personal opinion (and as author of RFC 8519) 
is that it should be -bis.

Cheers.

Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] WG adoption call: draft-boucadair-netmod-rfc8407bis-02

[Mahesh Jethanandani]

Support this effort, and agree that this document should be continuously 
updated as new recommendations are agreed upon.

> On Sep 11, 2023, at 3:22 PM, Lou Berger  wrote:
> 
> Hello,
> 
> This email begins a 2-week adoption poll for: 
> https://datatracker.ietf.org/doc/draft-boucadair-netmod-rfc8407bis/
> 
> Please voice your support or technical objections to adoption on the
> list by the end of the day (any time zone) Sept 25.
> 
> Thank you,
> Lou (as Co-chair)
> 


Mahesh Jethanandani
mjethanand...@gmail.com






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

[netmod] Where to rsync IETF YANG modules from [Was Re: List name: singular or plural?]

[Mahesh Jethanandani]

> On Aug 29, 2023, at 1:09 PM, Carsten Bormann  wrote:
> 
> Is there a good place where I can rsync IETF YANG modules from?

 rsync -avz --delete rsync.iana.org::assignments/yang-parameters 

Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Mahesh Jethanandani]

Support this work!

> On Aug 3, 2023, at 11:02 AM, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> This email begins a 2-week adoption poll for: 
> https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02 
> <https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02>
> 
> There is no known IPR on this draft (IPR call 
> <https://mailarchive.ietf.org/arch/msg/netmod/zJPEgqyi9yXzRqPO6NPJklQsBcU/>).
> 
> Please voice your support or technical objections to adoption on the list by 
> the end of the day (any time zone) Aug 17.
> 
> PS: I was hoping that Jeff would update the draft to reflect comments 
> received on-list (e.g., here 
> <https://mailarchive.ietf.org/arch/msg/netmod/8vk2TU2yaT8kLc1N7sbxiVs27UY/>) 
> before starting this poll, but he is going on PTO shortly and wouldn’t be 
> able to get to it for awhile, though he’s happy to do so upon returning.
> 
> Thank you,
> Kent (as Co-chair)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






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

[netmod] Comments on draft-ietf-netmod-acl-extensions

[Mahesh Jethanandani]

I do support this work to extend the ACL model defined in RFC 8519.

What I suggested on the mike was that the ICMP types be defined in an existing 
IANA YANG module. But my own search did not reveal an existing model that has 
type definitions where ICMP types could be added. I would suggest that the 
authors name the module something more generic than iana-icmp-types simply to 
allow future additions to the model for other type definitions, something like 
iana-acl-header-types.

The other question relates to how ICMP type are currently defined in RFC 8519. 
Is there a plan to update that type to the new types that will be defined in 
the IANA module? Is there a plan to include ICMP subtype (called code in RFC 
8519) both in the new IANA module, but also update RFC 8519 with the definition 
in the IANA module?

Regards

Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-08

[Mahesh Jethanandani]

I am not aware of any IPRs that apply to this draft.

> On Feb 16, 2023, at 11:07 AM, Lou Berger  wrote:
> 
> Authors, contributors,
> 
> As far as I tell those on the to line and listed below have not responded to 
> the IPR poll.  Either way, can the following please respond, even if doing so 
> again:
> Ebben Aries
> Juergen Schoenwaelder
> Mahesh Jethanandani
> Michael (Wangzitao)
> Jason Sterne
> 
> Thank you,
> 
> Lou
> 
> On 1/16/2023 5:53 PM, Lou Berger wrote:
>> Authors, Contributors, WG,
>> 
>> In preparation for WG Last Call
>> 
>> Are you aware of any IPR that applies to drafts identified above?
>> 
>> Please state either:
>> 
>> "No, I'm not aware of any IPR that applies to this draft"
>> or
>> "Yes, I'm aware of IPR that applies to this draft"
>> 
>> If so, has this IPR been disclosed in compliance with IETF IPR rules
>> (see RFCs 3669, 5378 and 8179 for more details)?
>> 
>> If yes to the above, please state either:
>> 
>> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>> or
>> "No, the IPR has not been disclosed"
>> 
>> If you answer no, please provide any additional details you think
>> appropriate. If you are listed as a document author or contributor
>> please answer the
>> above by responding to this email regardless of whether or not you are
>> aware of any relevant IPR. This document will not advance to the next
>> stage until a response has been received from each author.
>> 
>> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>> 
>> If you are on the WG email list or attend WG meetings but are not listed
>> as an author or contributor, we remind you of your obligations under
>> the IETF IPR rules which encourages you to notify the IETF if you are
>> aware of IPR of others on an IETF contribution, or to refrain from
>> participating in any contribution or discussion related to your
>> undisclosed IPR. For more information, please see
>> https://www.ietf.org/standards/ipr/
>> 
>> Thank you,
>> Lou and Kent
>> 
>> PS Please include all listed in the headers of this message in your
>> response.
>> 
>> 


Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] [Editorial Errata Reported] RFC8519 (7313)

[Mahesh Jethanandani]

In that case, yes, this errata should be accepted.

> On Jan 18, 2023, at 11:03 AM,  
>  wrote:
> 
> Hi Mahesh,
>  
> I also recall some of that discussion… but that is not related to this 
> erratum given the following prefix used in the import:
>  
> CURRENT:
>  import ietf-access-control-list {
>prefix acl;
>      }
>  
> Cheers,
> Med
>  
> De : Mahesh Jethanandani  
> Envoyé : mercredi 18 janvier 2023 19:32
> À : netmod 
> Cc : BOUCADAIR Mohamed INNOV/NET ; Sonal 
> Agarwal ; huangyi...@yahoo.com; d...@blairhome.com
> Objet : Re: [Editorial Errata Reported] RFC8519 (7313)
>  
> There was a lot of discussion on the usage of what prefix should be used when 
> importing a module, possibly after this draft was published. However, it is a 
> BCP, and most tools will not complain if a prefix other than what is defined 
> in the module is used. I am not sure if a BCP rises to the level of an errata.
>  
> Thanks.
> 
> 
> On Jan 18, 2023, at 7:02 AM, RFC Errata System  <mailto:rfc-edi...@rfc-editor.org>> wrote:
>  
> The following errata report has been submitted for RFC8519,
> "YANG Data Model for Network Access Control Lists (ACLs)".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7313 
> <https://www.rfc-editor.org/errata/eid7313>
> 
> --
> Type: Editorial
> Reported by: Mohamed Boucadair  <mailto:mohamed.boucad...@orange.com>>
> 
> Section: A.1
> 
> Original Text
> -
>   The following figure is the tree diagram of example-newco-acl.  In
>   this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
>   ietf-acl:matches are augmented with two new choices: protocol-
>   payload-choice and metadata.  The protocol-payload-choice uses a
>   grouping with an enumeration of all supported protocol values.
>   Metadata matches apply to fields associated with the packet, that are
>   not in the packet header, such as overall packet length.  In another
>   example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
>   ietf-acl:actions are augmented with a new choice of actions.
> 
> Corrected Text
> --
>   The following figure is the tree diagram of example-newco-acl.  In
>   this example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches
>   are augmented with two new choices: protocol-payload-choice and
>   metadata.  The protocol-payload-choice uses a
>   grouping with an enumeration of all supported protocol values.
>   Metadata matches apply to fields associated with the packet, that are
>   not in the packet header, such as overall packet length.  In another
>   example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions 
>   are augmented with a new choice of actions.
> 
> Notes
> -
> The prefix is "acl" not "ietf-acl"
> 
> ==
> module ietf-access-control-list {
>  yang-version 1.1;
>  namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
>  prefix acl;
>  ...
> ==
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --
> Title   : YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date: March 2019
> Author(s)   : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
>  
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
>  
>  
>  
>  
> 
>  
> _
> 
> 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 

Re: [netmod] [Editorial Errata Reported] RFC8519 (7313)

[Mahesh Jethanandani]

There was a lot of discussion on the usage of what prefix should be used when 
importing a module, possibly after this draft was published. However, it is a 
BCP, and most tools will not complain if a prefix other than what is defined in 
the module is used. I am not sure if a BCP rises to the level of an errata.

Thanks.

> On Jan 18, 2023, at 7:02 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC8519,
> "YANG Data Model for Network Access Control Lists (ACLs)".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7313
> 
> --
> Type: Editorial
> Reported by: Mohamed Boucadair 
> 
> Section: A.1
> 
> Original Text
> -
>   The following figure is the tree diagram of example-newco-acl.  In
>   this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
>   ietf-acl:matches are augmented with two new choices: protocol-
>   payload-choice and metadata.  The protocol-payload-choice uses a
>   grouping with an enumeration of all supported protocol values.
>   Metadata matches apply to fields associated with the packet, that are
>   not in the packet header, such as overall packet length.  In another
>   example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
>   ietf-acl:actions are augmented with a new choice of actions.
> 
> Corrected Text
> --
>   The following figure is the tree diagram of example-newco-acl.  In
>   this example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches
>   are augmented with two new choices: protocol-payload-choice and
>   metadata.  The protocol-payload-choice uses a
>   grouping with an enumeration of all supported protocol values.
>   Metadata matches apply to fields associated with the packet, that are
>   not in the packet header, such as overall packet length.  In another
>   example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions 
>   are augmented with a new choice of actions.
> 
> Notes
> -
> The prefix is "acl" not "ietf-acl"
> 
> ==
> module ietf-access-control-list {
>  yang-version 1.1;
>  namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
>  prefix acl;
>  ...
> ==
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --
> Title   : YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date: March 2019
> Author(s)   : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG


Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] [Editorial Errata Reported] RFC8519 (7312)

[Mahesh Jethanandani]

This errata should be accepted. Thanks.

> On Jan 18, 2023, at 6:29 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC8519,
> "YANG Data Model for Network Access Control Lists (ACLs)".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7312
> 
> --
> Type: Editorial
> Reported by: Mohamed Boucadair 
> 
> Section: A.1
> 
> Original Text
> -
>   The "example-newco-acl" module is an example of a company's
>   proprietary model that augments the "ietf-acl" module.  It shows how
>   to use 'augment' with an XML Path Language (XPath) expression to add
>   additional match criteria, actions, and default actions for when no
>   ACE matches are found.  All these are company proprietary extensions
>   or system feature extensions.  "example-newco-acl" is just an
>   example, and it is expected that vendors will create their own
>   proprietary models.
> 
> Corrected Text
> --
>   The "example-newco-acl" module is an example of a company's
>   proprietary model that augments the "ietf-access-control-list" module.  It 
> shows how
>   to use 'augment' with an XML Path Language (XPath) expression to add
>   additional match criteria, actions, and default actions for when no
>   ACE matches are found.  All these are company proprietary extensions
>   or system feature extensions.  "example-newco-acl" is just an
>   example, and it is expected that vendors will create their own
>   proprietary models.
> 
> Notes
> -
> There is no "ietf-acl" module in the document.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --
> Title   : YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date: March 2019
> Author(s)   : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG


Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] The NETMOD WG has placed draft-dbb-netmod-acl in state "Candidate for WG Adoption"

[Mahesh Jethanandani]

Is this in-lieu of a call for adoption, or did I somehow miss the call for 
adoption? I do see a separate IPR call.

Either ways, I do support the work, whether as a separate draft or as a bis of 
the original work. Would have preferred the latter, if not for anything else 
but to see how a YANG model can be updated in IETF. 

Cheers.

> On Dec 5, 2022, at 2:41 PM, IETF Secretariat 
>  wrote:
> 
> 
> The NETMOD WG has placed draft-dbb-netmod-acl in state
> Candidate for WG Adoption (entered by Lou Berger)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-dbb-netmod-acl/
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] [yang-doctors] Length on keys in YANG

[Mahesh Jethanandani]

In addition, and to Jeff’s point, we (in Arrcus) have started to deviate (and 
add) a constraint on the length of strings when they form part of the key, and 
when one is missing. It would be great to check for this as a practice, and/or 
add a type definition for a string type as suggested by Andy.

Thanks.

> On Oct 3, 2022, at 12:41 PM, Jeffrey Haas  wrote:
> 
> [I had promised Mahesh that I'd take my comments here, but I realize that this
> is a topic that likely will result in no short term solutions.  It may also
> result in no action whatsoever.]
> 
> YANG strings are bounded in length, theoretically, but that length limit
> isn't small.
> 
> When strings are used solely as leaf values, the length limit largely isn't
> a matter of concern, in my opinion.  However, when they're used as keys, it
> introduces some code practicalities that may be worth discussing.
> 
> One item of practicality is simply the length and its impact on underlying
> data structures.  If you were storing such things in something like a
> PATRICIA tree, many implementations behave better when the key is of a
> bounded length.*
> 
> A secondary consideration is that since unicode is used, character lengths
> in terms of storage may vary.  Implementations that internally store strings
> as UTF-8 have to be wary of truncation considerations.
> 
> A tertiary consideration is that in mechanisms like gNMI, long keys end up
> bloating PDUs.
> 
> Loosely framing this as a very old English joke: YANG Doctor, it hurts when
> I do this!  YANG Doctor: Well... don't do that!
> 
> For many things that have naturally short string names (e.g. interface
> names), this mostly isn't an issue.  However, for things that may take
> user-supplied strings as their key in configuration, this is somewhat more
> problematic.*
> 
> Most implementations likely don't take unbounded inputs to the maximum
> length of a YANG string for such things.  Technically in such situations,
> they're non-conformant if that's the case, or if they don't provide a
> deviation specifying the length of the string.
> 
> Why raise this?  While I only coincidentally participate in YANG module
> implementation at the moment, I remember similar headaches in MIBs making
> the lives of implementors problematic.
> 
> What should be done, if anything?  It seems like those with deeper expertise
> may want to recommend a reasonable length limit for strings that will be
> used as keys.  Perhaps define a specific typedef for such things.  And, once
> defined, the YANG doctors might consider recommending them in their reviews.
> 
> Such things may already be good practice, but perhaps I'm not aware of it.
> 
> -- Jeff
> 
> * As a matter of fact, it was performing a code review against exactly this
> point that raised this consideration.
> 
> ___
> yang-doctors mailing list
> yang-doct...@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors


Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] Confused about interface type

[Mahesh Jethanandani]

Hi Kent, 

I am using the -ii option in yanglint, which I am marks all the modules as 
implemented. 

I wonder if the issue is with the fact that ‘softwareLoopback’ is an identity 
with a base of iana-if-type, while the ‘type’ node is of type ‘interface-type’, 
even though iana-if-type has a base of interface-type. 

Thanks 

Mahesh Jethanandani 
mjethanand...@gmail.com

> On Aug 27, 2022, at 2:42 PM, Kent Watsen  wrote:
> 
> Ensure that all modules defining identities are *implemented*. 
> 
> In yanglint, the -i parameter or passing each module on the command line 
> causes them them be implemented. 
> 
> K. 
> 
> 
>>> On Aug 27, 2022, at 12:20 AM, Mahesh Jethanandani  
>>> wrote:
>>> 
>> I need some help figuring out why yanglint is giving me an error on the 
>> line marked below. I am using yanglint version 2.0.241
>> 
>> >xmlns:ipv4="urn:ietf:params:xml:ns:yang:ietf-ip">
>>   
>> loopback0
>>   >   
>> xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:softwareLoopback
>>   <—— This is where I get the error.
>>   
>> 
>> 
>> libyang err : Invalid identityref "ianaift:softwareLoopback" value - unable 
>> to map prefix to YANG schema. (Schema location 
>> "/ietf-interfaces:interfaces/interface/type", data location 
>> "/ietf-interfaces:interface[name='loopback0']", line number 10.)
>> 
>> The interfaces module defines the type node as:
>> 
>>   leaf type {
>> type identityref {
>>   base interface-type;
>> }
>> mandatory true;
>> 
>> and softwareLoopback is defined in iana-if-type module as:
>> 
>>   identity softwareLoopback {
>> base iana-interface-type;
>>   }
>> 
>> with iana-interface-type defined as:
>> 
>>   identity iana-interface-type {
>> base if:interface-type;
>> description
>>   "This identity is used as a base for all interface types
>>defined in the 'ifType definitions' registry.";
>>   }
>> 
>> Thanks
>> 
>> Mahesh Jethanandani
>> mjethanand...@gmail.com
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Confused about interface type

[Mahesh Jethanandani]

I need some help figuring out why yanglint is giving me an error on the line 
marked below. I am using yanglint version 2.0.241


  
loopback0
  ianaift:softwareLoopback
  <—— This is where I get the error.
  


libyang err : Invalid identityref "ianaift:softwareLoopback" value - unable to 
map prefix to YANG schema. (Schema location 
"/ietf-interfaces:interfaces/interface/type", data location 
"/ietf-interfaces:interface[name='loopback0']", line number 10.)

The interfaces module defines the type node as:

  leaf type {
type identityref {
  base interface-type;
}
mandatory true;

and softwareLoopback is defined in iana-if-type module as:

  identity softwareLoopback {
base iana-interface-type;
  }

with iana-interface-type defined as:

  identity iana-interface-type {
base if:interface-type;
description
  "This identity is used as a base for all interface types
   defined in the 'ifType definitions' registry.";
  }

Thanks

Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Mahesh Jethanandani]

I have followed the discussions on this draft and believe it is ready for 
publication. 

> 
> On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen 
>  wrote:
> 
> 
> Dear NETMOD WG,
> 
> This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11 
> ending on Friday, February 18th.  Here is a direct link to the HTML version 
> of the draft:
> 
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready 
> for publication", are welcome!  This is useful and important, even from 
> authors.  Objections, concerns, and suggestions are also welcomed at this 
> time.
> 
> Thank you,
> Kent (as co-chair)
> 
> ___
> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yangdoctors last call review of draft-ietf-netmod-node-tags-04

[Mahesh Jethanandani]

Hi Qin,

> On Feb 6, 2022, at 6:10 PM, Qin Wu  wrote:
> 
> Thanks Mahesh for valuable review. Please see reply inline below.
> 
> -Qin
>> -----邮件原件-
>> 发件人: Mahesh Jethanandani via Datatracker [mailto:nore...@ietf.org]
>> 发送时间: 2022年2月1日 13:25
>> 收件人: yang-doct...@ietf.org
>> 抄送: draft-ietf-netmod-node-tags@ietf.org; last-c...@ietf.org; 
>> netmod@ietf.org
>> 主题: Yangdoctors last call review of draft-ietf-netmod-node-tags-04
> 
>> Reviewer: Mahesh Jethanandani
>> Review result: On the Right Track
> 
>> Summary:
> 
>> This document defines a method to tag data objects associated with operation 
>> and management data in YANG Modules.  This YANG data object tagging method 
>> can be used to classify data objects from different YANG modules and 
>> identify characteristics 
>> data.
> 
>> Nits
> 
>> /subobjects/sub-objects/g
>> [Qin] Okay.
>> Comments:
> 
>> If the document updates RFC 8407, it needs to mention that in the Abstract.
>> Also the abstract can be shortened to what the document defines, and move 
>> everything else into the introduction.
> 
> 
> [Qin] Good point, similar comment was brought up by Adrian, I will make 
> Abstract short.
> 
>> The document says "This document defines an extension statement ...". Is 
>> only extension statement defined?
> [Qin]:I am not sure I capture your comment. But this document define one YANG 
> model, three extension statements and one IANA registry for IETF tags. Maybe 
> I should tweak this sentence as follows:
> "This document defines three extension statements..."

Yes, that would be helpful.

> 
>> Text like "data object tags may be registered as well as assigned during 
>> module definition" follow the pattern of RFC 8819 and should be referred to 
>> rather than duplicated. 
> [Qin]:Agree to reference to RFC8819, but this document focuses on data object 
> tags while RFC8819 focuses on model tag. I will see how to tweak the text to 
> reflect your comment.
> 
>> If assigned during implementation, is there a possibility that the same tag 
>> is assigned by two different implementations? What is the scope of a given 
>> data object tag?
> [Qin]: Note that the data object tags aim at data object classification. 
> Therefore the same tag can be assigned even by one implementation to 
> different data nodes. If the tag is the IETF tag defined in this document, we 
> need to make sure different 
> implementation or different device can assign the same tag to the same data 
> node in the module. For IETF tag, we should make sure the tag is unique. Same 
> rule is applied to other vendor tag or user tag, But we don't suggest to use 
> IETF tag together with
> either vendor tag or user tags. Hope this clarifies.
> 
>> Similarly, the draft says "objects can be one of container, leaf-list and 
>> list". Did you mean to say "objects can be one of type container, leaf-list 
>> and list"?
> [Qin]: Correct, I can tweak the text as you suggested.
> 
>> The example in Figure 2 can be improved. For example, if all the data 
>> objects are for the module name "tunnel-pm", do you need the last column. 
> [Qin]: I can take out the last column or keep the last column and remove 
> duplicated text in each row by merging all the rows associated with last 
> column into one row.
> 
>> More importantly, it is not clear why tunnel-src/max-latency (why a gap 
>> between / and max-latency), is not an object tag? Can a sub-object tag exist 
>> if the node is not an object tag?
> 
> [Qin] As shown in figure 1 and figure 2, you will see only root node will be 
> tagged as object tag, in figure 2, only tunnel-svc can be seen as root node, 
> tunnel-svc/max-latency is just a child node and therefore can not be tagged 
> with *theobject tag *. Please also refer to section9.2 table for clear 
> definition of object tag.
> Secondly sub-object tag and object tag can not tag the same node, only root 
> node will be tagged with object tag, Sub-object will be tagged with 
> sub-object tags such as property tag, metric tag, metric-type tag, 
> multi-source tag.
> 
>> In Section 4, Data Object Tag Values, it says tags can be any value except 
>> carriage-returns, newlines and tabs. Does it mean spaces are allowed? Can a 
>> data object have multiple tags? What does it mean "No further structure is 
>> imposed ..."?
> [Qin]: I think tabs is similar to spaces, maybe 2 spaces or 4 spaces but with 
> less disk space / memory / compiler resource.

In that case, it would be helpful to mention it so.

> Secondly

Re: [netmod] Use XML namespaces in YANG document examples

[Mahesh Jethanandani]

;urn:ietf:params:xml:ns:yang:iana-if-type">
>  
>eth0
>ianaift:ethernetCsmacd
>DHCPv6 Relay Interface
>true
>  
>
> 
> The question is related to the use of the ‘ianaift:’ prefix. This is quite 
> commonly use in XML examples in YANG documents (e.g. RFC8344) so I think the 
> question is generally applicable.
> 
> The specific comments from the expert review are:
> 
> -
> For the correct processing of these documents requires that whatever XML 
> software is being used makes available to application code the namespace 
> prefixes.
> 
> Whilst the recommended tools (e.g. yanglint) provides this function, it is 
> not an XML best practice. Quoting from the Namespaces in XML, section 4: 
> "Note that the prefix functions only as a placeholder for a namespace name. 
> Applications SHOULD use the namespace name, not the prefix, in constructing 
> names whose scope extends beyond the containing document.”
> 
> I think that violating a SHOULD assertion in a W3C standard is a problem.
> 
> There is no requirement for XML processors to provide this prefix 
> information, and software that (quite legally) doesn't, will not work 
> correctly with YANG documents constructed as specified in this I-D.
> 
> 1, YANG specifications should note this fact and specify that software which 
> is used to process YANG documents MUST provide an interface such that 
> applications can retrieve the prefix-namespace mappings.
> 2, For constructs such as ianaift:ethernetCsmacd the 
> Internet-Draft should specify that the prefix ("ianaift" in this case) MUST 
> be identical to the xmlns namespace prefix representing the namespace name 
> urn:ietf:params:xml:ns:yang:iana-if-type
> 3, Alternately, the draft could specify that for the namespace 
> urn:ietf:params:xml:ns:yang:iana-if-type, the XML namespace prefix ianaift 
> MUST be used. Another XML bad practice because software that generates XML 
> programmatically should feel free to generate synthetic prefixes without 
> breaking the content, but at least this would solve the problem.
> -
> 
> BCP216 (RFC8407 - Guidelines for Authors and Reviewers of Documents 
> Containing YANG modules) doesn’t make any mention of how XML namespaces 
> should be used, only that example XML/ JSON should be included and that these 
> examples need to be validated (pyang and yanglint are mentioned for this).
> 
> Does this guidance need to be updated to reflect expert review comments above?
> 
> Thanks,
> Ian
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






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

[netmod] Yangdoctors last call review of draft-ietf-netmod-node-tags-04

[Mahesh Jethanandani via Datatracker]

Reviewer: Mahesh Jethanandani
Review result: On the Right Track

Summary:

This document defines a method to tag data objects associated with operation
and management data in YANG Modules.  This YANG data object tagging method can
be used to classify data objects from different YANG modules and identify
characteristics data.

Nits

/subobjects/sub-objects/g

Comments:

If the document updates RFC 8407, it needs to mention that in the Abstract.
Also the abstract can be shortened to what the document defines, and move
everything else into the introduction.

The document says "This document defines an extension statement ...". Is only
extension statement defined?

Text like "data object tags may be registered as well as assigned during module
definition" follow the pattern of RFC 8819 and should be referred to rather
than duplicated. If assigned during implementation, is there a possibility that
the same tag is assigned by two different implementations? What is the scope of
a given data object tag?

Similarly, the draft says "objects can be one of container, leaf-list and
list". Did you mean to say "objects can be one of type container, leaf-list and
list"?

The example in Figure 2 can be improved. For example, if all the data objects
are for the module name "tunnel-pm", do you need the last column. More
importantly, it is not clear why tunnel-src/max-latency (why a gap between /
and max-latency), is not an object tag? Can a sub-object tag exist if the node
is not an object tag?

In Section 4, Data Object Tag Values, it says tags can be any value except
carriage-returns, newlines and tabs. Does it mean spaces are allowed? Can a
data object have multiple tags? What does it mean "No further structure is
imposed ..."?

Section 4.2 introduces the concept of vendor prefix for tags. It says vendors
include extra identification in the tag to avoid collision. But what is to say
that two organizations may not use the same identification? And is this
identifier part of the tag or is separated from the tag with a :.

Similarly, it says that user prefix is RECOMMENDED. If not using it can cause
collision, why is use prefix RECOMMENDED and not a MUST?

The draft has just one example. And it shows mostly ietf prefixed tags. More
examples showing use of different types of tags are needed. It would be helpful
to know how tags can be removed.

Section 5 - YANG Module.

The section does not reference the RFCs that it imports modules from, e.g.
ietf-netcom-acm.

Inside the YANG model, import statements need to carry reference statement.

The WG link needs to refer to datatracker.ietf.org and not tools.ietf.org

The Copyright statement has 2021 as the year.

Line length should be limited to 72 columns.

No need to repeat parent name in child node, e.g. object-name -> name.

Indentation is off in places, specially in the example.

A pyang compilation of the model with —ietf and —lint option was clean.

A idnits run of the draft reveals a few issues. Please address them.

draft-ietf-netmod-node-tags-04.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ---

 No issues found here.

  Checking nits according to
  https://www.ietf.org/id-info/1id-guidelines.txt:
  ---

 No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ---

  ** There are 70 instances of too long lines in the document, the
 longest one being 15 characters in excess of 72.

  -- The draft header indicates that this document updates RFC8407,
 but the abstract doesn't seem to mention this, which it should.

  Miscellaneous warnings:
  ---

  == The copyright year in the IETF Trust and authors Copyright Line
 does not match the current year

  == Line 404 has weird spacing: '...ct-namenac...'

  == Line 493 has weird spacing: '...dentify  multi...'

  == Line 656 has weird spacing: '...resents  a pro...'

  == Line 999 has weird spacing: '...dentify  multi...'

  -- The document date (November 2021) is 77 days in the past.  Is
 this intentional?

  Checking references for intended status: Proposed Standard
  ---

 (See RFCs 3967 and 4897 for information about using normative
 references to lower-maturity documents in RFCs)

  == Missing Reference: 'I-D.netconf-notification-capabilities' is
 mentioned on line 139, but not defined

  == Missing Reference: 'I-D.ietf-netmod-yang-instance-file-format'
 is mentioned on line 1106, but not defined

 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2
 comments (--).

 Run idnits wit

Re: [netmod] Yang string with patterns cannot be assigned default values

[Mahesh Jethanandani]

I believe if you remove the anchor characters ^ and & from the pattern 
statement, the default value will work.

> On Nov 3, 2021, at 12:06 PM, Olumide <50...@web.de> wrote:
> 
> Dear List,
> 
> yanglint (version 0.16.105) does not validate the schema below when the
> a default value is assigned to string that has a pattern. Is this the
> specified behavior; and if so is there a workaround? (Comments not in
> schema, added for emphasis)
> 
>module tmp
>{
>namespace "example.com";
>prefix "foo";
> 
>container bar {
>leaf wibble {
>type string {
>pattern "^x$";
>}
>default "x";  ### NOT OKAY
>}
> 
>leaf wobble {
>type string;
>default "y"; ### OKAY
>}
>}
>}
> 
> 
> yanglint error message:
> 
> err : Value "x" does not satisfy the constraint "^x$" (range, length, or
> pattern). (/tmp:wibble)
> err : Module "tmp" parsing failed.
> 
> 
> Regards,
> 
> - Olumide
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] New Version Notification for draft-dbb-netmod-acl-00.txt

[Mahesh Jethanandani]

Hi,

The NETMOD WG has the following GitHub repository to track issues related to 
the ACL model. It would make sense to open issues against the model there, and 
discuss them on the netmod mailing list. The WG can then decide based on the 
issues opened whether a -bis document is warranted or not.

https://github.com/netmod-wg/acl-model/issues 
<https://github.com/netmod-wg/acl-model/issues>

Thanks

> On Oct 19, 2021, at 9:33 AM, Oscar González de Dios 
>  wrote:
> 
> Dear Netmod colleagues,
> 
>We discussed in the list some time ago a few possible enhancements on 
> the ACL Yang model (RFC 8519).
> 
>Following the suggestions received the list, we've prepared an 
> individual draft in which we document the motivation of several enhacements 
> to the Access control list Yang model. Note that, in this first version of 
> the document, we have not included on purpose any yang model. We are seeking 
> the work direction from the netmod WG whether the missing features can be 
> accomplished by means of augmentations or whether an ACL-bis document  is 
> more appropriate.
> 
>   Looking forward to receiving your comments / thoughts/ 
> suggestions.
> 
>Best Regards,
> 
>Oscar, Samier, Med
> 
> -Mensaje original-
> De: internet-dra...@ietf.org 
> Enviado el: lunes, 18 de octubre de 2021 13:06
> Para: Mohamed Boucadair ; Oscar González de 
> Dios ; Oscar González de Dios 
> ; SAMIER BARGUIL GIRALDO 
> ; SAMIER BARGUIL GIRALDO 
> 
> Asunto: New Version Notification for draft-dbb-netmod-acl-00.txt
> 
> 
> A new version of I-D, draft-dbb-netmod-acl-00.txt has been successfully 
> submitted by Oscar Gonzalez de Dios and posted to the IETF repository.
> 
> Name:   draft-dbb-netmod-acl
> Revision:   00
> Title:  Extensions to the Access Control Lists (ACLs) YANG Model
> Document date:  2021-10-18
> Group:  Individual Submission
> Pages:  18
> URL:https://www.ietf.org/archive/id/draft-dbb-netmod-acl-00.txt
> Status: https://datatracker.ietf.org/doc/draft-dbb-netmod-acl/
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-dbb-netmod-acl
> 
> 
> Abstract:
>   RFC 8519 defines a YANG data model for Access Control Lists (ACLs).
>   This document discusses a set of extensions that fix many of the
>   limitations of the ACL model as initially defined in RFC 8519.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, 
> puede contener información privilegiada o confidencial y es para uso 
> exclusivo de la persona o entidad de destino. Si no es usted. el destinatario 
> indicado, queda notificado de que la lectura, utilización, divulgación y/o 
> copia sin autorización puede estar prohibida en virtud de la legislación 
> vigente. Si ha recibido este mensaje por error, le rogamos que nos lo 
> comunique inmediatamente por esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential 
> information intended only for the use of the individual or entity named 
> above. If the reader of this message is not the intended recipient, you are 
> hereby notified that any dissemination, distribution or copying of this 
> communication is strictly prohibited. If you have received this transmission 
> in error, do not read it. Please immediately reply to the sender that you 
> have received this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, 
> pode conter informação privilegiada ou confidencial e é para uso exclusivo da 
> pessoa ou entidade de destino. Se não é vossa senhoria o destinatário 
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia 
> sem autorização pode estar proibida em virtude da legislação vigente. Se 
> recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente 
> por esta mesma via e proceda a sua destruição
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] [babel] NULL value for uint16

[Mahesh Jethanandani]

Hi Martin,

> On Sep 14, 2021, at 11:17 AM, Martin Björklund  wrote:
> 
> Mahesh Jethanandani  <mailto:mjethanand...@gmail.com>> wrote:
>> Hi Juergen,
>> 
>>> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder 
>>>  wrote:
>>> 
>>> On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:
>>> 
>>>> As I mentioned, BBF TR-181 uses int with range -1:65535 with -1 
>>>> meaning NULL. So I certainly have no issue with that approach. The 
>>>> language in RFC9046 was intended to make sure this approach was allowed, 
>>>> since this is how it's done in TR-181.
>>>> I guess I am a bit surprised to learn that YANG doesn't seem to have a 
>>>> preferred way to handle this. Unfortunately, given my considerable lack of 
>>>> YANG expertise, I can't recommend the "right" way to model this in YANG. I 
>>>> can only insist that the model be able to express a value in the range 0 
>>>> to 2^16 and NULL value for these parameters. 
>>>> Independent of the fact that the words in RFC9046 don't seem to have 
>>>> expressed this perfectly clearly, that is absolutely the intent of those 
>>>> words. I apologize that the RFC9046 words don't seem to be sufficiently 
>>>> clear. 
>>>> 
>>>> Since you do mention the possibility of using -1 for NULL, I'd like to 
>>>> understand who might find this approach unacceptable? The language in the 
>>>> information model was definitely intended to express the acceptability of 
>>>> using this approach from a Babel WG perspective (because I knew that's how 
>>>> it would be done in TR-181). Would this be unacceptable to people with 
>>>> YANG expertise? I think my preference would be to use this approach, since 
>>>> it would provide additional consistency between the TR-181 and YANG models.
>>> 
>>> If other data models use an extended integer range and -1 to indicate
>>> a special case, then this may be a strong reason to do the same in the
>>> IETF YANG data model. Consistency across data models is a value, in
>>> particular for systems that may have to support multiple. While the
>>> conversion of different notations no hard, its one more thing to
>>> potentially get wrong.
>>> 
>>> If you were starting with a blank sheet of paper, then the YANG idiom
>>> would likely be to use a union of a 16-bit integer and a special
>>> (string) value, which might even be of type empty.
>> 
>> I hear two suggestions on what the “other” construct should be in the union 
>> statement. Use ‘empty’ as you suggest, or use ‘boolean’. Are there any 
>> pros/cons for either of the approaches?
> 
> 'boolean' doesn't seem right, since that would mean that you could see
> the values 'true' | 'false' | .
> 
> If you want a union I suggest a union with one enum, perhaps:
> 
>  type union {
>type enumeration {
>  enum null;
>}
>type uint16;
>  }
> 
> But Jürgens point about using a solution that other data models use
> makes sense.

That would mean something like this:

type union {
  type empty;
  type uint16;
}

Right?

> 
> Yet another alternative could be to not instantiate this leaf when the
> value in the information model is null.

I have never been very clear on what happens when the leaf goes from a defined 
value to null. In other words, how do you “un-instantiate” a leaf? Do you 
delete it?

Cheers.

> 
> 
> 
> /martin
> 
> 
> 
> 
> 
>> 
>>> 
>>> One of the reasons to have no common approach to these kind of
>>> questions is to provide the flexibility needed to do the right thing
>>> in different contexts. Of course, you may want to stay consistent in a
>>> data model or a collection of related data model.
>>> 
>>> I skimmed RFC 8407 and it seems we do not have text discussion this
>>> specific situation. Perhaps we should have text, perhaps I have
>>> overlooked it. ;-) I think there are different patterns to choose from
>>> to handle this situation with their various pros and cons.
>>> 
>>> /js
>>> 
>>> -- 
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
>> 
>> Mahesh Jethanandani
>> mjethanand...@gmail.com

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] [babel] NULL value for uint16

[Mahesh Jethanandani]

Hi Juergen,

> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder 
>  wrote:
> 
> On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:
> 
>> As I mentioned, BBF TR-181 uses int with range   -1:65535 with -1 
>> meaning NULL. So I certainly have no issue with that approach. The language 
>> in RFC9046 was intended to make sure this approach was allowed, since this 
>> is how it's done in TR-181.
>> I guess I am a bit surprised to learn that YANG doesn't seem to have a 
>> preferred way to handle this. Unfortunately, given my considerable lack of 
>> YANG expertise, I can't recommend the "right" way to model this in YANG. I 
>> can only insist that the model be able to express a value in the range 0 to 
>> 2^16 and NULL value for these parameters. 
>> Independent of the fact that the words in RFC9046 don't seem to have 
>> expressed this perfectly clearly, that is absolutely the intent of those 
>> words. I apologize that the RFC9046 words don't seem to be sufficiently 
>> clear. 
>> 
>> Since you do mention the possibility of using -1 for NULL, I'd like to 
>> understand who might find this approach unacceptable? The language in the 
>> information model was definitely intended to express the acceptability of 
>> using this approach from a Babel WG perspective (because I knew that's how 
>> it would be done in TR-181). Would this be unacceptable to people with YANG 
>> expertise? I think my preference would be to use this approach, since it 
>> would provide additional consistency between the TR-181 and YANG models.
> 
> If other data models use an extended integer range and -1 to indicate
> a special case, then this may be a strong reason to do the same in the
> IETF YANG data model. Consistency across data models is a value, in
> particular for systems that may have to support multiple. While the
> conversion of different notations no hard, its one more thing to
> potentially get wrong.
> 
> If you were starting with a blank sheet of paper, then the YANG idiom
> would likely be to use a union of a 16-bit integer and a special
> (string) value, which might even be of type empty.

I hear two suggestions on what the “other” construct should be in the union 
statement. Use ‘empty’ as you suggest, or use ‘boolean’. Are there any 
pros/cons for either of the approaches?

> 
> One of the reasons to have no common approach to these kind of
> questions is to provide the flexibility needed to do the right thing
> in different contexts. Of course, you may want to stay consistent in a
> data model or a collection of related data model.
> 
> I skimmed RFC 8407 and it seems we do not have text discussion this
> specific situation. Perhaps we should have text, perhaps I have
> overlooked it. ;-) I think there are different patterns to choose from
> to handle this situation with their various pros and cons.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] NULL value for uint16

[Mahesh Jethanandani]

[Bringing in babel WG, instead of maintaining two threads]


Hi Juergen,


> On Sep 10, 2021, at 1:09 PM, Jürgen Schönwälder 
>  wrote:
> 
> On Fri, Sep 10, 2021 at 01:40:03PM -0400, Lou Berger wrote:
> 
>> and it references an RFC that says:
>> 
>>  This is a 16-bit unsigned integer;
>>  if the data model uses zero (0) to represent NULL values for
>>  unsigned integers, the data model MAY use a different data type
>>  that allows differentiation between zero (0) and NULL.
> 
> We are talking about RFC 9046? RFC 9046 repeats this sentence several
> times but I find it difficult to infer the intended meaning. If 0 is a
> legal value, you can't have it represent "NULL" at the same time.

There are five definitions in the Babel YANG model 
<https://www.ietf.org/archive/id/draft-ietf-babel-yang-model-11.html> that use 
NULL to represent a special meaning.

With ‘babel-route-received-metric’, and ‘babel-route-calculated-metric’ values 
use NULL or 0 to represent that a route was NOT received. A non-zero value 
indicates that a route was received and subsequently advertised.

With ‘babel-expo-mcast-hello-seqno’, and ‘babel-exp-ucast-hello-seqno’ a value 
of NULL or 0 is used to represent that a multicast, or unicast hello packets 
respectively are NOT expected or processing of multicast/unicast packets is not 
enabled. Although not explicit stated, it also means that the sequence number 
cannot be a 0.

Finally, with ‘babel-ucast-hello-seqno’ a value of NULL or 0 is used to 
represent a unicast hello is not being sent. A non-zero value reflects the 
current sequence number in use for unicast hellos. Again, although not 
explicit, it also means that the sequence number cannot be a 0.

> 
> In YANG, we tend to not instantiate leafs that do not have a value.
> Anyway, if a YANG author wants to report a special value to indicate
> that there is no value, then you have design for it and reserve and
> set aside a special value from the number space or use a union.

This YANG model reserves the value of 0 to indicate that these leafs are not 
set or the particular attribute is not enabled.

Thanks.

> 
> RFC 9046 uses the same text for things like sequence numbers. Skimming
> RFC 8966, it seems sequence numbers are 16-bit integers:
> 
>   Sequence numbers (seqnos) appear in a number of Babel data
>   structures, and they are interpreted as integers modulo 2^(16).
> 
> The text in the context makes me believe they are an unsigned 16-bit
> integers. If so, there simply is no way to use 0 to indicate that a
> sequence number is absent. The problem really might be the text in RFC
> 9046.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] Unknown idnits error

[Mahesh Jethanandani]

I assume that this is during the submit process, and that you are not running 
this offline. Submit a report to to...@ietf.org <mailto:to...@ietf.org> and 
have them look at it.

> On Sep 9, 2021, at 10:12 AM, Balázs Lengyel 
>  wrote:
> 
> Hello,
> I am trying to check/submit a new version of my 
> draft-ietf-netmod-yang-instance-file-format-18.
>  
> The previous version did not have any idnits errors or warnings. Now suddenly 
> I get: 
>  
> == Couldn't figure out when the document was first submitted -- there may
>  comments or warnings related to the use of a disclaimer for pre-RFC5378
>  work that could not be issued because of this.  Please check the Legal
>  Provisions document at https://trustee.ietf.org/license-info 
> <https://trustee.ietf.org/license-info> to determine
>  if you need the pre-RFC5378 disclaimer.
> I did not change any boilerplate info. Why do I get this warning and how to 
> get rid of it?
>  
> I use xml2rfc. My draft includes:
>  
>  docName="draft-ietf-netmod-yang-instance-file-format-18">
> 
>  
> Help, Balazs
>  
>  
> -- 
> Balazs LengyelSenior Specialist   
> Ericsson Hungary Ltd. 
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 
> <mailto:balazs.leng...@ericsson.com>
>  
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] Use of prefixes in YANG models

[Mahesh Jethanandani]

> On Mar 19, 2021, at 12:46 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Mar 19, 2021 at 09:23:06AM +, tom petch wrote:
>> 
>> If  the spec was more precise it would settle the arguments.
>> 
> 
> RFC 7950 says that tools must support a prefix statement inside an
> import statement, which overrides the prefix defined in the imported
> module. A tool that does not support this is not implementing RFC 7950
> correctly.
> 
> RFC 8407 provides additional rules for authors writing IETF YANG
> modules. Implementations may generate warnings (perhaps even errors,
> may be implementation specific) if these rules are violated by modules
> to which the RFC 8407 rules apply. (This implies that a tool needs to
> know whether RFC 8407 rules apply or not.)

I believe support by tools for the additional rules imposed by RFC 8407 would 
be helpful. There are several ways to recognize that the module in question is 
an IETF module, e.g. namespace, or by a more direct option on the tool CLI, 
e.g. —ietf option in pyang. The tools can print a warning if the prefix of the 
imported module is not used.

> 
> It is true that RFC 8407 is not very explicit to which YANG modules
> the rules apply but given the many IETF specific rules, it is kind of
> implicit that the rules may not apply 1:1 to YANG modules published by
> other organizations.

Additionally, RFC 8407 is a BCP. It does not update RFC 7950. However, it is 
changing the prefix requirement for import in RFC 7950, from a SHOULD to a 
MUST. Aren’t languages supposed to be consistent in how its rules are meant to 
be interpreted?

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

Mahesh Jethanandani
mjethanand...@gmail.com





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

[netmod] Use of prefixes in YANG models

[Mahesh Jethanandani]

I have seen the debate on the use of prefixes in YANG models, specially as it 
relates to their use when importing a model. I think it would nice to be clear 
on what is required, what is nice, and what is not ok to do. I do not want to 
confuse this discussion with the length of the prefix, which I believe is 
somewhat related but not the same discussion.

RFC 7950 says:

   All prefixes, including the prefix for the module itself, MUST be
   unique within the module or submodule.

This is a requirement, as is clear by the MUST.

Then RFC 7950 says:

   To
   improve readability of YANG modules, the prefix defined by a module
   SHOULD be used when the module is imported, unless there is a
   conflict.

It also says:

   When used inside the "import" statement, the "prefix" statement
   defines the prefix to be used when accessing definitions inside the
   imported module.

Clearly, the scope of the “prefix" statement used with an “import” statement is 
limited to the module where it is imported and does not impact the imported 
module. As such, and because it is a SHOULD and not a MUST, this is a “nice to 
have”  without conflicts, but one would not be wrong using a different prefix 
from the one defined in the imported module. Add to this, most tools, e.g. 
pyang or yanglint do not complain if you do define a different prefix when 
there are no conflicts. I have not seen a problem in the implementation of the 
module when the prefix is different.

RFC 8407 confuses this whole situation by saying:

  The proper module prefix MUST be used for all identifiers imported
  from other modules.

which as written is true for identifiers (but not for other types of 
imports??). Besides, it does not define what is “proper module prefix". In the 
absence of a proper definition, one should follow what RFC 7950 says.

Comments?

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] Liaison statement to ORAN

[Mahesh Jethanandani]

Hi Balazs,

Do you have an example of where O-RAN is trying to deviate a 3GPP model? I 
would agree that for O-RAN to deviate a model would be a problem, and that it 
should be left to vendors to decide if they want to deviate the 3GPP model.

> On Nov 18, 2020, at 12:09 AM, Balázs Lengyel 
>  wrote:
> 
> Hello,
> In connection to the draft 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01 
> <https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01> I propose to 
> send a liaison statement from IETF Netmod to ORAN.
>  
> The issue: 3GPP is standardizing a good number of YANG modules as part of the 
> 3gpp TS 28.541 and 28.623 
> (https://forge.3gpp.org/rep/sa5/MnS/tree/Rel17-draft/yang-models 
> <https://forge.3gpp.org/rep/sa5/MnS/tree/Rel17-draft/yang-models>). 
> ORAN plans to re-use this models, but possibly refine them in some ways. They 
> are considering using deviations to do this. 
> E.g. change config=true schemas node to config=false. This creates problems 
> as documented in 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1 
> <https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01%23section-5.8.1>
>  
> -   Deviations by an SDO (standard defining organization) prevent 
> implementations from reporting their own deviations for the same nodes.
> -   Deviations by an SDO prevent implementations from conforming to the 
> standards specified by both SDOs.
>  
> To avoid these problems I propose to send the following text to ORAN:
>  
> “IETF NETMOD working group requests ORAN to avoid using deviations as part of 
> its specification. As documented in 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1 
> <https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01%23section-5.8.1>
>  the usage of deviations would prevent:
> Vendors to implement their own deviations for the same YANG schema nodes
> Vendors to claim conformance to both ORAN and 3GPP specifications which are 
> in some cases used as a base for the ORAN YANG models
> Note: These problems with deviations exists even if YANG modules are used 
> without using YANG packages.
> Regards Balazs
>  
> -- 
> Balazs LengyelSenior Specialist   
> Ericsson Hungary Ltd. 
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 
> <mailto:balazs.leng...@ericsson.com>
>  
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] submodules the hidden benefits

[Mahesh Jethanandani]

A contrarian view:

I find the use of sub-modules helpful when I want to use separate files to 
maintain part of the module that is logically separate, while 
maintaining/restricting the use of them to a single namespace.

The fact that tools have a problem with trying to compile a sub-module can be 
addressed in the tools themselves.

> On Aug 5, 2020, at 2:44 PM, Reshad Rahman (rrahman) 
>  wrote:
> 
> Indeed
> https://github.com/netmod-wg/yang-next/issues/26
> 
> On 2020-08-05, 5:22 PM, "netmod on behalf of Vladimir Vassilev" 
>  
> wrote:
> 
>On 05/08/2020 18.48, Juergen Schoenwaelder wrote:
> 
>> I personally meanwhile believe that sub-modules add complexity with
>> little extra value but this view surely is not shared by others.
> 
>+1. IMO removing sub-modules from YANG 2.0 should be on the list of 
>proposed changes.
> 
>/Vladimir
> 
>___
>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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

[Mahesh Jethanandani]

+1.

> On Apr 24, 2020, at 12:39 PM, Sterne, Jason (Nokia - CA/Ottawa) 
>  wrote:
> 
> That seems like a reasonable approach to me.
> Jason
>  
> From: netmod  On Behalf Of Rob Wilton (rwilton)
> Sent: Friday, April 24, 2020 3:34 PM
> To: Kent Watsen ; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>  
> Hi Kent,
>  
> Thanks for creating the issue.
>  
> I think that errata falls under section 7 
> ofhttps://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ 
> , 
> and could be classified as “Hold for Document Update”.  I.e. “Changes that 
> modify the working of a protocol to something that might be different from 
> the intended consensus when the document was approved should be either Hold 
> for Document Update or Rejected. Deciding between these two depends on 
> judgment. Changes that are clearly modifications to the intended consensus, 
> or involve large textual changes, should be Rejected. In unclear situations, 
> small changes can be Hold for Document Update.”
>  
> I think that the consensus of the long term fix (e.g. in YANG 1.2) is that 
> “require-instance” should be allowed under typedefs that refined types that 
> allow it.
>  
> Pragmatically, I think that we can mark this errata is a “Hold for Document 
> Update”, with the accompanying errata notes (derived from Radek’s comments) 
> changed to:
>  
> “The document does not specify whether the “require-instance” keyword is 
> allowed in typedef refinements derived from the “leafref” or 
> “instance-identifier” base types, but it is anticipated that a future 
> revision of YANG would allow this.   It is suggested that modules using YANG 
> language versions 1 [RFC 6020] and 1.1 [RFC 7950] avoid using this construct, 
> YANG module validation tools flag a warning if this construct is used, but 
> implementations allow this if possible.”
>  
> Does anyone object to this course of action (or wishes to refine my errata 
> notes)?
>  
> Regards,
> Rob
>  
>  
> From: Kent Watsen mailto:kent+i...@watsen.net>> 
> Sent: 23 April 2020 17:59
> To: Andy Bierman mailto:a...@yumaworks.com>>
> Cc: Radek Krejci mailto:rkre...@cesnet.cz>>; Juergen 
> Schoenwaelder  >; Martin Björklund 
> mailto:mbj+i...@4668.se>>; netmod@ietf.org 
> ; Rob Wilton (rwilton)  >
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>  
> The consensus seems to be that:
>   - the errata should be rejected
> - Rob, do you agree?
>   - YANG-next should fix it later
> - I created https://github.com/netmod-wg/yang-next/issues/104 
> 
>   - implementations should try to do the right thing now
> - Radek’s suggestion below LGTM!
>  
>  
> Tallies:
>- for reject: Andy, Martin, Juergen, and Kent 
>- for accept: Radek, and Balazs
>- unclear: Lada, Rob, and Jason
>  
>  
> Kent // as co-chair
>  
>  
> 
> On Apr 14, 2020, at 10:35 AM, Andy Bierman  > wrote:
>  
> Hi,
>  
> I agree with Juergen that this errata should be rejected and the issue 
> resolved in yang-next.
> No IETF module should use this construct. It is easy to convert to an 
> equivalent form that is not under dispute.
>  
>  
> Andy
>  
>  
> On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci  > wrote:
> Hi,
> 
> Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):
>  
>  
> 
> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder 
>  > wrote:
>  
> The definition I found in RFC 8639 is this:
> 
>leaf stream {
>  type stream-ref {
>require-instance false;
>  }
>  mandatory true;
>  description
>"Indicates the event stream to be considered for
> this subscription.";
>}
> 
> This could be changed to:
> 
>leaf stream {
>  type leafref {
> path "/sn:streams/sn:stream/sn:name";
>require-instance false;
>  }
>  mandatory true;
>  description
>"Indicates the event stream to be considered for
> this subscription.";
>}
> 
>  
> I can confirm that `yanglint` validates the module cleanly after this change.
>  
>  
>  
> On Apr 6, 2020, at 7:38 AM, Martin Björklund  > wrote:
>  
> I think the correct fix is to change the text so that
> "require-instance" is not classified as a restriction and keep the
> default.  
>  
> Agreed.
>  
>  
> 
> Also, I think that it would be easiest (for backwards
> compatibility w/ existing models) to allow "require-inetance" to be
> changed in derived types.
> 
> However, this cannot imo be done in an errata.
>  
> While I appreciate Radek and Michal’s perspective, I also think that is would 
> be best for the 

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

[Mahesh Jethanandani]

As someone who has reviewed the draft, I want to say I support the work. The 
draft is short and easy to read.

Thanks.

> On Mar 26, 2020, at 11:46 AM, Kent Watsen  wrote:
> 
> Dear All,
> 
> This WGLC has received zero responses, which is insufficient to progress the 
> document at this time.  The WGLC is therefore being extended  for another 
> week, now ending April 1st (the day before our Virtual Meeting on April 2nd). 
>  
> 
> Again, positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcomed.  This is useful and important, even 
> from authors.  Objections, concerns, and suggestions are also welcomed at 
> this time.
> 
> FWIW, the YANG Doctor review was completed on 3/23 (thanks Mahesh) with the 
> “Ready with Nits” status: 
> https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23
>  
> .
> 
> Kent // as shepherd and co-chair
> 
> 
> 
>> On Mar 9, 2020, at 6:30 PM, Kent Watsen > > wrote:
>> 
>> This message begins an almost two-week WGLC for 
>> draft-ietf-netmod-geo-location-04 ending on March 22nd (the day before the 
>> NETMOD sessions).  Here is a direct link to the HTML version of the draft:
>> 
>>  https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04 
>> 
>> 
>> Positive comments, e.g., "I've reviewed this document and believe it is 
>> ready for publication", are welcome!  This is useful and important, even 
>> from authors. Objections, concerns, and suggestions are also welcomed at 
>> this time.
>> 
>> Thank you,
>> NETMOD Chairs
>> 
>> ___
>> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Yangdoctors last call review of draft-ietf-netmod-geo-location-04

[Mahesh Jethanandani via Datatracker]

Reviewer: Mahesh Jethanandani
Review result: Ready with Nits

I am not an expert in geo location. If my understanding of the geo location
model is incorrect, feel free to educate me and everyone else. This review is
looking at the draft from a YANG perspective. With that said, I have marked it
as Ready with Nits, because of some of the points discussed below.

Summary:

This document defines a YANG data model for a generic geographical location. It
is a short document and it is well written and easy to read.

Nits

Section 5.1.3

s/mapped using the using the/mapped using the/

Comments:

Section 3

- Please add references for models that are imported, both in the model and in
the document. For example, in the draft before the YANG model you should have
something like.

This model imports Common YANG Data Types [RFC6991].

And in the model itself

OLD:
import ietf-yang-types { prefix types; }

NEW:
import ietf-yang-types {
  prefix types;
  reference
"RFC 6991: Common YANG Data Types.";
}

The choice of decimal64 with different fractional values must have been
discussed in the WG. However, as the author has noted several times in the
model, that it was chosen over double or strings, even as it left the model
with loss of precision during any conversion to and from e.g. the URI defined
by RFC 5870. It would be worthwhile capturing the reason for the choice, e.g.
the language does not have a built-in type for double, or for not using a
string??

A pyang compilation of the model with —ietf and —lint option was clean. The
example also validated against ietf-geo-location and example YANG model.

A idnits run of the draft reveals a few issues. Cannot say all of them are
valid errors, so ignore them as necessary.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  

  ** There is 1 instance of too long lines in the document, the longest one
 being 1 character in excess of 72.

  Miscellaneous warnings:
  

  -- The document date (September 2020) is 176 days in the future.  Is this
 intentional?

  Checking references for intended status: Proposed Standard
  

 (See RFCs 3967 and 4897 for information about using normative references
 to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'EGM08'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'EGM96'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS84'

 Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).

 Run idnits with the --verbose option for more detailed information about
 the items above.


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

[netmod] yanglint errors for ietf-subscribed-notifications

[Mahesh Jethanandani]

As I mentioned in the other thread, I am seeing errors while trying to use 
yanglint to validate examples for modules that import 
ietf-subscribed-notifications. I see it with ietf-notification-capabilities and 
with my own draft ietf-https-notif. These errors do not appear with confd. 

Using ietf-notification-capabilites and the first example in the -12 version of 
the draft which I call examples-notification-capabilities-1.xml, and released 
models for ietf-yang-push and ietf-subscribed-notifications, I see two issues. 
The first one related to the statement 'required-instance’ in 
ietf-subscribed-notifications is discussed on the other thread, and I do not 
want to repeat it here. If I comment out the only instance of 
‘required-instance’ in the module, I run into more errors:

bash-3.2$ yanglint -s -i -t auto -p /Volumes/External/git/iana/yang-parameters/ 
ietf-system-capabilit...@2020-03-08.yang 
ietf-notification-capabilit...@2020-03-09.yang 
examples-notification-capabilities-1.xml 
err : The leafref leaf is config but refers to a non-config leaf. 
(/ietf-subscribed-notifications:subscriptions/subscription/target/stream/stream)
err : Invalid value "subscription-policy" of "uses". 
(/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy)
err : Copying data from grouping failed. 
(/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy)
err : Module "ietf-subscribed-notifications" parsing failed.
err : Importing "ietf-subscribed-notifications" module into "ietf-yang-push" 
failed.
err : Module "ietf-yang-push" parsing failed.
err : Importing "ietf-yang-push" module into "ietf-notification-capabilities" 
failed.
err : Module "ietf-notification-capabilities" parsing failed.

While pyang gives the following error:

bash-3.2$  pyang -f tree ietf-subscribed-notificati...@2019-09-09.yang > 
ietf-subscribed-notificati...@2019-09-09-tree.txt
ietf-subscribed-notificati...@2019-09-09.yang:381: error: the path for stream 
is config but refers to a non-config leaf "name" defined at 
ietf-subscribed-notificati...@2019-09-09.yang:1046

Have other encountered this error? If we agree this is an error, is there a 
-bis to fix this?

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Regarding IPR on draft-verdt-netmod-yang-solutions-03

[Mahesh Jethanandani]

No, I am not aware of any IPR that applies to this draft.

> On Mar 2, 2020, at 2:13 PM, Lou Berger  wrote:
> 
> 
> Authors, Contributors, WG,
> 
> As part of preparation for WG Adoption:
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> We note that all DT members are listed as contributors.  If you contributed 
> to the document please respond.  Alternatively, please feel free to state 
> that you didn't materially contribute to the draft and would like your name 
> removed from the contribution section (and moved to acknowledgments after WG 
> adoption).
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author.
> 
> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 
> 
> ___
> 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] [Netmod-ver-dt] Regarding IPR on draft-verdt-netmod-yang-schema-comparison-00

[Mahesh Jethanandani]

Thanks to Benoit for pointing out …

No, I am not aware of any IPR that applies to this draft.

Cheers.

> On Mar 2, 2020, at 2:13 PM, Lou Berger  wrote:
> 
> 
> Authors, Contributors, WG,
> 
> As part of preparation for WG Adoption:
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> We note that all DT members are listed as contributors.  If you contributed 
> to the document please respond.  Alternatively, please feel free to state 
> that you didn't materially contribute to the draft and would like your name 
> removed from the contribution section (and moved to acknowledgments after WG 
> adoption).
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author.
> 
> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 
> 
> ___
> Netmod-ver-dt mailing list
> netmod-ver...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

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

Re: [netmod] validating instance data against YANG schema including 'must' statements

[Mahesh Jethanandani]

Hi Jason,

yanglint does validate XML instance data for must statements:

MAHESH-M-M8D1:/Volumes/External/git/my-YANG-public/src/model/draft *833 > 
yanglint -t auto -s -i -p common 
.../../../build/mef-legato-servi...@2018-07-17.yang 
MEF6.2-bwp-per-uni-mef-interface-configuration.xml 
err : Must condition ". >= 1 and . <= count(../../bwp-flow/rank)" not 
satisfied. 
(/mef-legato-interfaces:mef-interfaces/carrier-ethernet/subscriber-interfaces/uni[uni-id='ciscoD21:GigabitEthernet0/0/0/1']/ingress-envelopes/envelope[id='ciscoD21-per-cos-env2']/bwp-flows/bwp-flow[rank='3']/rank)
err : The rank of a Bandwidth Profile Flow must be
between 1 and n, where n is the number of flows
in the Envelope 
(/mef-legato-interfaces:mef-interfaces/carrier-ethernet/subscriber-interfaces/uni[uni-id='ciscoD21:GigabitEthernet0/0/0/1']/ingress-envelopes/envelope[id='ciscoD21-per-cos-env2']/bwp-flows/bwp-flow[rank='3']/rank)

> On Jan 31, 2020, at 8:21 AM, Sterne, Jason (Nokia - CA/Ottawa) 
>  wrote:
> 
> Thx Lada.
> 
> If I only have XML (e.g. from a NETCONF interface) I suppose I could use 
> yanglint, e.g. this type of usage:
> yanglint--format=json--type=config   --output=data.json   
> ./all-my-modules/*.yang ./data.xml
> 
> Is that correct?
> 
> I believe yanglint can also validate instance data against a YANG schema. Can 
> anyone confirm that yang2dsdl and yanglint do *not* validate against the 
> 'must' statements?
> 
> Jason
> 
>> -Original Message-
>> From: netmod  On Behalf Of Ladislav Lhotka
>> Sent: Friday, December 13, 2019 2:59 AM
>> To: netmod@ietf.org
>> Subject: Re: [netmod] validating instance data against YANG schema including
>> 'must' statements
>> 
>> On Thu, 2019-12-12 at 16:42 +, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>>> Hi all,
>>> 
>>> A few years ago there were a few discussions on the list about tools to
>>> validate instance data (e.g. the data returned by a ) against a
>>> YANG model.
>>> 
>>> yang2dsdl is one option but I'm pretty sure it doesn't actually check the 
>>> data
>>> against 'must' statements.
>>> 
>>> Are there some tools that check against 'must' (and 'when') statements?
>> Do
>>> those tools also work with YANG 1.1 modules?
>> 
>> Yangson does a complete validation, and supports YANG 1.1, but only JSON
>> representation of instance data. The GitHub link is below, a PyPI package is
>> also available:
>> 
>> https://pypi.org/project/yangson/
>> 
>> Lada
>> 
>>> 
>>> Thx,
>>> Jason
>>> 
>>> 
>> ###
>> ###
>>> 
>>> Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 => 16.10-5..1
>>> Ladislav Lhotka  Tue, 07 March 2017 12:42 UTCShow
>> header
>>> 
>>> Kent Watsen ; writes:
>>> 
 Hi Benoit,
 
 You seem to know the ins and outs of many tools these days, maybe you
 can point me in the right direction...which tool is able to validate
 instance documents against YANG 1.1 modules?
>>> 
>>> Yangson can validate JSON documents:
>>> 
>>> https://github.com/CZ-NIC/yangson
>>> 
 
 I've always used `yang2dsdl`, but currently it outputs "DSDL plugin
 supports only YANG version 1".
>>> 
>>> I considered updating the DSDL plugin to 1.1 but it turned up to be
>>> immensely difficult - it would basically require a complete rewrite. And
>>> even then, the Schematron implementation that is included in pyang
>>> distribution won't support the new XPath functions.
>>> 
>>> Lada
>>> 
>>> 
>> ###
>> ###
>>> 
>>> 
>>> Re: [netmod] DSDL plugin in pyang
>>> Ladislav Lhotka  Tue, 29 November 2016 13:39 UTCShow
>> header
>>> 
>>> Hi William,
>>> 
>>> apart from yang2dsdl, I have personal experience with these two instance
>>> validation tools:
>>> 
>>> * yanglint - written in C, supports both XML and JSON instance encoding
>>> 
>>>  https://github.com/CESNET/libyang
>>> 
>>> * yangson - written in Python, supports only JSON
>>> 
>>>  https://github.com/CZ-NIC/yangson
>>>  installation: pip install yangson
>>>  manual page: http://yangson.readthedocs.io/en/latest/cmdline.html
>>> 
>>> Lada
>>> 
>>> William Lupton ; writes:
>>> 
 Are you able to provide a list (either privately or via the NETMOD list) of
>>> other instance data validators that are available and cover YANG 1.1
>> features?
>>> Tx, W.
 
> On 25 Nov 2016, at 14:33, Ladislav Lhotka ; wrote:
> 
> Hi,
> 
> for users of $subj: I modified the plugin so that it now immediately
>>> refuses to process modules of yang-version greater than 1. Supporting some
>> of
>>> the YANG 1.1 features (new XPath functions, leafref handling) would require
>>> massive changes and I cannot do them now - I am not even sure it is worth
>> the
>>> effort given that other instance data validators are available.
> 
> Lada
>>> 
>>> --
>>> 
>>> 
>> 

Re: [netmod] ID submission YANG validation errors?

[Mahesh Jethanandani]

> On Jan 22, 2020, at 6:40 AM, Christian Hopps  wrote:
> 
> 
> I've just submitted a YANG module draft and received what i think to be a 
> bogus validation error:
> 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/
> 
> It's saying it can't find the ietf-isis module. Has anyone else experienced 
> this issue with referencing draft modules? It seems broken that we can't 
> refer to works-in-progress, inside our works-in-progress.

Yes, I experience this error all the time. In this case I am referencing 
published IEEE models in YangModels GitHub location. If my local validation 
passes, I just ignore these errors:

yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} 
{model} -i:
err : Data model "ieee802-dot1q-types" not found.
err : Importing "ieee802-dot1q-types" module into "ietf-if-l3-vlan" failed.
err : Module "ietf-if-l3-vlan" parsing failed.
err : Importing "ietf-if-l3-vlan" module into "ietf-routing-policy" failed.
err : Module "ietf-routing-policy" parsing failed.
err : Importing "ietf-routing-policy" module into "ietf-bgp" failed.
err : Module "ietf-bgp" parsing failed.

> 
> Thanks,
> Chris.
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



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

[netmod] Schema mount and Network Instance model

[Mahesh Jethanandani]

The network-instances YANG model [RFC8529] gives an example in Appendix A.1 of how to use schema mount to mount the routing protocol. An example modeled along those lines for the BGP YANG model, and enclosed herewith fails validation using yanglint with the following error. What am I doing wrong?Validating yang/example-bgp-configuration-a.1.3.xmlerr : Unknown element "routing". (/ietf-network-instance:network-instances/network-instance[name='vrf-red']/vrf-root)failed (error code: 0)With confdc it fails as follows:Loading Data for example a.1.3confd_load: 666: maapi_load_config(sock, tid, flags, abspath(argv[0])) failed: external error (19): Error on line 9: unknown element: routing in /ni:network-instances/ni:network-instance[ni:name='vrf-red']/ni:vrf-root/rt:routingIf what I have is not an error, it raises two questions. Is schema mount supported? Supported from a validation perspective. I can imagine that not everyone (or anyone) may have actually implemented schema mount. And the second and more important question is how are routing protocols supposed to support VRF if the two models, network instance and routing protocol, do not work together? What needs to change to get them to work?Thanks.
Mahesh Jethanandanimjethanand...@gmail.com





example-bgp-configuration-a.1.3.xml
Description: XML document
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Mahesh Jethanandani]

Hi Qin,

> On Nov 5, 2019, at 4:35 PM, Qin Wu  wrote:
> 
> 2. Suggest to add a
>> paragraph in the section 5 to explain which common type or type in 
>> specific module is imported
> [RW] 
> 
> Please can you clarify this comment, because I'm not sure what you are 
> requesting here.  I've left an open issue to track this:  
> https://github.com/netmod-wg/interface-extensions-yang/issues/21
> 
> [Qin]: See 1st paragraph, section 4 of RFC8344 as an example.

[mj] You mean to say that the draft should specify which RFCs the module 
imports typedefs from, and which RFCs it references in the model somewhere in 
the draft. For example, it imports ietf-yang-types and therefore should refer 
to RFC 6991 somewhere in the draft (but outside the model). Right?

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

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] PYANG refine fault ?

[Mahesh Jethanandani]

Hi Balasz,

In general support of unions is poor across the tool sets that I have used. It 
does not help that yanglint gives a completely different error.

I did try yanger, and that did not result in an error.

The other option is to move the default statement inside the grouping, which 
seems to make the error go away.

Cheers.

> On Oct 9, 2019, at 8:01 AM, Balázs Lengyel 
>  wrote:
> 
> Hello,
> I was trying to validate the attached model. However pyang keeps complaining 
> about refining a default for a leaf-list:
>  
> ietf-notification-capabilit...@2019-10-10.yang 
> <mailto:ietf-notification-capabilit...@2019-10-10.yang>:184: error: 
> "leaf-list" node 
> "ietf-notification-capabilities::supported-excluded-change-type" cannot be 
> refined with "default"
>  
> Why? According to https://tools.ietf.org/html/rfc7950#section-7.13.2 
> <https://tools.ietf.org/html/rfc7950#section-7.13.2> “A leaf-list node may 
> get a set of default values ...” 
> .
> Confdc accepts this. Could this be a bug in pyang ?
> Regards Balazs
>  
> -- 
> Balazs LengyelSenior Specialist   
> Ericsson Hungary Ltd. 
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 
> <mailto:balazs.leng...@ericsson.com>
>  
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] References to the "tags" typedef

[Mahesh Jethanandani]

> On Oct 3, 2019, at 2:37 AM, Rob Wilton (rwilton)  wrote:
> 
> Hi Chris,
> 
> I know that this is late, but ...
> 
> The YANG packages draft 
> (https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-01, but an 
> updated version will be posted soon), is currently using the module-tags 
> typedef to allow a package definition to contain a list of tags.
> 
> E.g. 
> module: ietf-yang-package
>   +--ro yang-package
>  +--ro name  yang:yang-identifier
>  +--ro version   yang-sem-ver
>  +--ro revision-date?yanglib:revision-identifier
>  +--ro location* inet:uri
>  +--ro description?  string
>  +--ro reference?string
>  +--ro previous-version? yang-sem-ver
>  +--ro tag*  tags:tag
>  +--ro referentially-complete?   Boolean
>  ...
> 
> This package definition goes into an instance data document, for which the 
> schema should just be ietf-yang-package, but by it importing 
> ietf-module-tags.yang, it effectively also pulls in the "container 
> module-tags" into the schema for the package definition, that I don't think 
> should be there.
> 
> If we keep package tags, then I think that there are two ways to fix this:
> 
> (1) Split ietf-module-tags into an ietf-module-tags-types.yang and a 
> ietf-module-tags.yang.  But it would be very late to do this, and the 
> packages draft isn't even a workgroup document at this stage.

I know it is late. But what will it take to split the tags-types module from 
the tags module?

> 
> (2) Have the package draft define its own "package tag" typedef, and not have 
> an import reference on module-tags at all.  Probably if we do keep package 
> tags, then we should also consider a mechanism by which they can be updated 
> on a device equivalently to module tags.
> 
> I'm currently thinking that the second choice might be a better approach at 
> this time, but wanted to check whether you or the WG had an opinion.
> 
> Thanks,
> Rob
> 
> 
> 
>> -Original Message-
>> From: netmod  On Behalf Of Christian Hopps
>> Sent: 25 September 2019 17:19
>> To: netmod@ietf.org
>> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-module-tags-09.txt
>> 
>> This adds the deprecated non-NMDA state module.
>> 
>> Thanks,
>> Chris.
>> 
>>> On Sep 25, 2019, at 12:15 PM, internet-dra...@ietf.org wrote:
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>> This draft is a work item of the Network Modeling WG of the IETF.
>>> 
>>>   Title   : YANG Module Tags
>>>   Authors : Christian Hopps
>>> Lou Berger
>>> Dean Bogdanovic
>>> Filename: draft-ietf-netmod-module-tags-09.txt
>>> Pages   : 18
>>> Date: 2019-09-25
>>> 
>>> Abstract:
>>>  This document provides for the association of tags with YANG modules.
>>>  The expectation is for such tags to be used to help classify and
>>>  organize modules.  A method for defining, reading and writing a
>>>  modules tags is provided.  Tags may be registered and assigned during
>>>  module definition; assigned by implementations; or dynamically
>>>  defined and set by users.  This document also provides guidance to
>>>  future model writers; as such, this document updates RFC8407.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-09
>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-09
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-09
>>> 
>>> 
>>> 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/
>>> 
>>> ___
>>> 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

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] 6991bis - Any plans to add more URI Syntax components?

[Mahesh Jethanandani]

Hi Juergen

Ok. I had most of the definitions as strings with no pattern restrictions. On 
your prompting, I started to put them together. Note, I do not have a 
definition for ‘path’ as yet. I will work on it next. For the remaining, here 
is what I came up with. I have not tested all of them with all possible 
patterns, so I am sure some of them will need tweaking.

  typedef scheme {
type string {
  pattern '([a-zA-Z][a-zA-Z\d+-.]*)';
}
description
  "Each URI begins with a scheme name that refers to a 
   specification for assigning identifiers within that scheme.";
reference
  "RFC 3986, Section 3.1: URI Generic Syntax.";
  }

  typedef userinfo {
type string {
  pattern '(([a-zA-Z\d\-._~\!$\'()*+,;=%]*)@?)';
}
description
  "The userinfo subcomponent consists of a user name.
   The user information, if present, is followed by an optional
   commercial at-sign ('@') that delimits it from the host.";
reference
  "RFC 3986, Section 3.2.1: URI Generic Syntax.";
  }

  typedef query {
type string {
  pattern '\?([a-zA-Z\d\-._~\!$\'()*+,;=]*)';
}
description
  "The query component contains non-hierarchical data that,
   along with data in the path component,
   serves to identify a resource within the scope of the
   URI's scheme and naming authority (if any).";
reference
  "RFC 3986, Section 3.4: URI Generic Syntax.";
  }

  typedef fragment {
type string {
  pattern '\#([a-zA-Z\d\-._~\!$\'()*+,;=]*)?$';
}
description
  "The fragment identifier component of a URI allows indirect
   identification of a secondary resource by reference to a
   primary resource and additional identifying information.
   The identified secondary resource may be some portion or
   subset of the primary resource, some view on representations
   of the primary resource, or some other resource defined or
   described by those representations.";
reference
  "RFC 3986, Section 3.5: URI Generic Syntax.";
  }

Cheers.

> On Oct 1, 2019, at 1:54 AM, Schönwälder, Jürgen 
>  wrote:
> 
> Mahesh,
> 
> can you share you definitions so that people can look at them and take
> an informed decision whether this is something they can use as well?
> Having some concrete use cases (in the IETF) is likely useful to make
> something a common YANG datatype.
> 
> /js
> 
> On Mon, Sep 30, 2019 at 02:27:49PM -0700, Mahesh Jethanandani wrote:
>> Hi Juergen,
>> 
>>> On Sep 28, 2019, at 1:57 AM, Schönwälder, Jürgen 
>>>  wrote:
>>> 
>>> Hi Mahesh,
>>> 
>>> are these frequently needed? Are there YANG modules that use these
>>> fields already?
>> 
>> Over in ETSI, I just added them to the YANG model that defines VNF 
>> Descriptors (VNFD), as part of what is called VnfConfigurableProperties.
>> 
>> In addition, I know that draft-kwatsen-netconf-http-client-server draft 
>> tries to define 'user-id'. And there has been discussion around 
>> draft-ietf-netconf-https-notif needing to define a ‘path’ attribute, 
>> although Martin does not think it is needed. Anyway, these are the instances 
>> I know of that could use these definitions. I am sure there are more.
>> 
>> Cheers.
>> 
>>> 
>>> /js
>>> 
>>> On Fri, Sep 27, 2019 at 06:39:54PM -0700, Mahesh Jethanandani wrote:
>>>> Hi Juergen,
>>>> 
>>>> Is there a plan to add more URI syntax components in rfc6991bis? I know 
>>>> there is a typedef for uri, but I was looking specifically for the 
>>>> following that are defined in RFC 3986.
>>>> Scheme
>>>> Authority field including
>>>> User information
>>>> Path
>>>> Query
>>>> Fragment
>>>> 
>>>> Thanks.
>>>> 
>>>> Mahesh Jethanandani
>>>> mjethanand...@gmail.com
>>>> 
>>>> 
>>>> 
>>> 
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> 
>>> -- 
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
>> 
>> Mahesh Jethanandani
>> mjethanand...@gmail.com
>> 
>> 
>> 
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] 6991bis - Any plans to add more URI Syntax components?

[Mahesh Jethanandani]

Hi Juergen,

> On Sep 28, 2019, at 1:57 AM, Schönwälder, Jürgen 
>  wrote:
> 
> Hi Mahesh,
> 
> are these frequently needed? Are there YANG modules that use these
> fields already?

Over in ETSI, I just added them to the YANG model that defines VNF Descriptors 
(VNFD), as part of what is called VnfConfigurableProperties.

In addition, I know that draft-kwatsen-netconf-http-client-server draft tries 
to define 'user-id'. And there has been discussion around 
draft-ietf-netconf-https-notif needing to define a ‘path’ attribute, although 
Martin does not think it is needed. Anyway, these are the instances I know of 
that could use these definitions. I am sure there are more.

Cheers.

> 
> /js
> 
> On Fri, Sep 27, 2019 at 06:39:54PM -0700, Mahesh Jethanandani wrote:
>> Hi Juergen,
>> 
>> Is there a plan to add more URI syntax components in rfc6991bis? I know 
>> there is a typedef for uri, but I was looking specifically for the following 
>> that are defined in RFC 3986.
>> Scheme
>> Authority field including
>> User information
>> Path
>> Query
>> Fragment
>> 
>> Thanks.
>> 
>> Mahesh Jethanandani
>> mjethanand...@gmail.com
>> 
>> 
>> 
> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

Mahesh Jethanandani
mjethanand...@gmail.com



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

[netmod] 6991bis - Any plans to add more URI Syntax components?

[Mahesh Jethanandani]

Hi Juergen,

Is there a plan to add more URI syntax components in rfc6991bis? I know there 
is a typedef for uri, but I was looking specifically for the following that are 
defined in RFC 3986.
Scheme
Authority field including
User information
Path
Query
Fragment

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

[Mahesh Jethanandani]

Hi Dmytro,

First of all, I find the discussion within the netmod WG as just the wrong 
place to have this discussion. You will be hard pressed to find too many people 
who can give you critical feedback on the model in this WG.

See inline with [mj]

> On Sep 5, 2019, at 2:03 PM, Dmytro Shytyi  wrote:
> 
> [Dmytro]
> Hello Mahesh Jethanandani,
> Thank you for your comment.
> Please find answers inline.
> 
> >I find the representation of a service model in this draft for a uCPE as too 
> >simple. In reality, on a uCPE, you could be running a Network Service (NS), 
> >which is composed of multiple VNFs interconnected together. This service 
> >model does not address such a configuration.
> [Dmytro]
> This service model presented in the draft supports N VMs in the NS and 
> addreses configuration with multiple VMs and switches with plenty of links. 
> It is well tested (with service chained VMs) on equipent from different well 
> known suppliers. The idea to have complex flexible service in the network 
> service orchestrator for uCPE.
> in the yang model we have list (marked by pyang with "*") of VMs where the 
> key is name of the vm, thus you may define as much VM as you wish.

[mj] You have introduced concept of interfaces, ports, and switches that does 
not exist in the NFV world. VNFs have virtual links and connection points. 
There is no (physical) port or interface that one connects to in a VNF. It 
might exist on the server on which the VM runs but not in a VNF or a 
virtualization instance.

> 
> Example of 2 VMs that are service chained (swLAN-VM1-swService-VM2-swWAN)
> 
>   +--rw vms* [vm]
>   +--rw vm string
>   +--rw ports* [port]
>   |  +--rw portstring
>   |  +--rw name?   string
>   |  +--rw link?   -> ../../../links/link
>   +--rw ram?   string
>   +--rw cpu?   string
>   +--rw storages* [id]
>   |  +--rw id  string
>   |  +--rw location?   string
>   +--rw day0-config
>  +--rw location?string
>  +--rw day0-var-path?   string
>  +--rw variable* [name]
> +--rw name string
> +--rw value?   string
> 
> 
> So basically  the list "+--rw wms* [vm]" can be represented/"expanded" in 
> this way where the names and number ov vms(N) is set by user:
> 
>  >>>>>   +--rw vm1 string
>| +--rw ports* [port]
>| |  +--rw portstring
>| |  +--rw name?   string
>| |  +--rw link?   -> ../../../links/link
>| +--rw ram?   string
>| +--rw cpu?   string
>| +--rw storages* [id]
>| |  +--rw id  string
>| |  +--rw location?   string
>| +--rw day0-config
>| |  +--rw location?string
>| |  +--rw day0-var-path?   string
>| |  +--rw variable* [name]
>| | +--rw name string
>| | +--rw value?   string
> >>>>>+--rw vm2 string
>| +--rw ports* [port]
>| |  +--rw portstring
>| |  +--rw name?   string
>| |  +--rw link?   -> ../../../links/link
>| +--rw ram?   string
>| +--rw cpu?   string
>| +--rw storages* [id]
>| |+--rw id  string
>| |  +--rw location?   string
>| +--rw day0-config
>| |+--rw location?string
>| |  +--rw day0-var-path?   string
>| |  +--rw variable* [name]
>| | +--rw name string
>| | +--rw value?   string
> 
>   |  
>  >>>>>   +--rw vmN string
> +--rw ports* [port]
> |  +--rw port

Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

[Mahesh Jethanandani]

e VM/VNF in the uCPE could be a vROuter or Vfirewall or an SD-WAN that is 
> >not a default part of virtual network resources of the uCPE (chapter 3 in 
> >the ID).
> >The switch (ex. Open vSwith) in the uCPE is a default part of uCPE network 
> >virtual resources (chapter 3 in the ID).
> >Thus we need to distingish swithes and VNFs to not to mix uCPE network 
> >virtual resources and VNFs.
> >Another reason why the destingishing is required: because VM and SW have 
> >different device-attributes. SW does not require VNFD attributtes.
> >If we do not distinguish nodes, and only extend the grouping "device 
> >attributes" for required attributes the switch will have the properties that 
> >are  unused leafs which represent the VM-device-attributes.
> >>VNF lifecycle management is separated from topology construction, wrong?
> >[Dmytro]:
> >a) In case of the NFVIs uCPE the same High Level interface allows to 
> >configure both topology construction and VM lifecycle management in the same 
> >transaction.
> >b) We can not activate Network Service Descriptor without consituent VM node 
> >information. At the moment of NSD activation we already have to set the VM 
> >node information such as VM capabilities that can be created (previosly)/(at 
> >the moment of configuration of NSD) but have to be a part of the network 
> >service descriptor at the moment of activation.
> >[Dmytro]
> >The Internet Draft also defines the term uCPE that is not defined at IETF 
> >yet.
> >___
> >netmod mailing list
> >netmod@ietf.org <mailto:netmod@ietf.org>
> >https://www.ietf.org/mailman/listinfo/netmod 
> ><https://www.ietf.org/mailman/listinfo/netmod>
> 
> __
> Dmytro SHYTYI
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] [Technical Errata Reported] RFC8519 (5762)

[Mahesh Jethanandani]

This errata should be rejected for the following reason.

The whole idea of defining the identities for acl-type was to allow vendors to 
specify what capabilities their box is capable of supporting and then to 
specify what capabilities the vendors want to support. As such there is no 
“default capability" for every vendor. Besides, if a device advertises a 
mixed-eth-ipv4 feature, it is because it can only support Ethernet and IPv4 ACL 
combinations, and it cannot support IPv6 ACL matches. You do not add a 
capability of IPv6 match on the fly. It either has it, or it does not. If it 
does, advertise mixed-eth-ipv4-ipv6 capability to begin with.

> On Jun 23, 2019, at 8:58 PM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC8519,
> "YANG Data Model for Network Access Control Lists (ACLs)".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5762
> 
> --
> Type: Technical
> Reported by: Qin WU 
> 
> Section: 4.1
> 
> Original Text
> -
> leaf type {
> type acl-type;
> description
>  "Type of ACL.  Indicates the primary intended
>   type of match criteria (e.g., Ethernet, 
>   IPv4, IPv6, mixed, etc.) used in the list
>   instance.";
> }
> 
> Corrected Text
> --
> leaf type {
> type acl-type;
> default "ipv4-acl-type";
> description
>  "Type of ACL.  Indicates the primary intended
>   type of match criteria (e.g., Ethernet, 
>   IPv4, IPv6, mixed, etc.) used in the list
>   instance.";
> }
> 
> Notes
> -
> I am wondering why not  set default value for acl-type,e.g., set default 
> value as "ipv4-acl-type" otherwise, how to determine which field under which 
> choice will be matched upon and which action should be taken on them if the 
> opetional parameter type under acl list is not set.
> 
> Also I want to better understand why acl type is removed from key indexes of 
> access list and keep it as optional parameter under acl list. One case I am 
> thinking in my mind is we add a mixed Ethernet, IPv4, and IPv6 ACL entry when 
> we already have Ethernet ACL entry,IPv4 ACL entry , we don't need to remove 
> existing ethernet entry and existing IPv4 entry in the list ("aces") and 
> create a new entry with mixed ethernet, IPv4, IPv6 ACL, instead, we just add 
> a new identity called mixed-eth-ipv4-ipv6-acl-type and add a new IPv6 entry.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --
> Title   : YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date: March 2019
> Author(s)   : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] 6991bis: address-with-prefix-length

[Mahesh Jethanandani]

> On Apr 2, 2019, at 11:27 AM, Martin Bjorklund  wrote:
> 
> And for the record (again, perhaps), I think this is a bad idea in
> general, and I am not sure an exception is needed in this case.

+1

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] 6991bis: address-with-prefix-length

[Mahesh Jethanandani]

> On Apr 1, 2019, at 12:37 PM, Kristian Larsson  wrote:
> 
> 
> 
>> On 2019-04-01 19:29, Martin Bjorklund wrote:
>> Hi,
>> The request was for a combined type that contains both an ip address
>> *and* a prefix length in one value.  Hence the name
>> "ip-address-and-prefix-length" :)
> 
> Right you are, though I'm open to other names but let's first agree on use 
> case / need :)
> 
> 
>> I know that this type is convenient, esp. if you use it for manual
>> input, but I wonder if it really is good practice to squeeze two
>> values into one.
> 
> Dunno how "manual" has any bearing. This is IMHO just about natural data 
> modeling.
> 
> You say it's two values but when one can't be used without the other, are 
> they so separated? You can't configure an interface with just an address or 
> just a subnet mask. You need both - they belong together.

That can be modeled into the data module, I.e. that you have to specify both 
the address and the prefix length. 

The reason Martin mentioned two values is because even if they are modeled with 
a ‘/‘ character, the end system will consume them as two separate values.

> 
> Similarly, in a routing table you have prefixes, which consist of an address 
> and a length - it got its own data type yet you could apply your argument to 
> it and say they should be separated. It's just that *that* data type forbids 
> bits to be set in the mask portion of the address, which is correct for the 
> routing table use case, but means it can't be used to describe an interface 
> address and mask.
> 
>  kll


Mahesh Jethanandani
mjethanand...@gmail.com

> 
> 
> 
> 
>> /martin
>> "Acee Lindem (acee)"  wrote:
>>> Ok, now I'm confused. I see that the ietf-inet-type model already has the 
>>> types ipv4-prefix and ipv6-prefix. How are these any different???
>>> Thanks,
>>> Acee
>>> 
>>> On 4/1/19, 12:31 PM, "Acee Lindem (acee)"  wrote:
>>> 
>>>I believe the "address-" could be omitted from the type identifiers. At 
>>> least within the routing area, "ipv4-prefix" is unambiguous.
>>>Thanks,
>>>Acee
>>> On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder" 
>>>  
>>> wrote:
>>> This is the right time for this and I would call these
>>>ip-address-prefix, ipv4-address-prefix and ipv6-address
>>>prefix.
>>> /js
>>>> On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson 
>>>> wrote:
>>>> Hello,
>>>> 
>>>> seeing that 6991 is up for a refresh I wonder if this would be the time to
>>>> suggest the addition of a type for address-and-prefix-length, for example
>>>> like 192.0.2.1/24?
>>>> 
>>>> I find that it's the most natural way express the address and prefix-length
>>>> to configure on an interface or for some other use. We currently have an
>>>> ip-prefix type which allows CIDR style prefixes but since all bits to the
>>>> right of the mask is to be 0 it is only possible to use for describing the
>>>> IP prefix / network address itself - not the address of a host in that
>>>> network.
>>>> 
>>>> I actually wish the interface-ip modules would have used a combined leaf 
>>>> for
>>>> these settings rather than the dual-leaf approach it currently has, but I
>>>> suppose that ship has sailed :/
>>>> 
>>>> Regardless, can we add such a type? Is this the document and time to do it?
>>>> :)
>>>> 
>>>> Kind regard,
>>>>   Kristian.
>>>> 
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> --
>>>Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
>>> Germany
>>>Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
>>> ___
>>>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 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] 6991bis: address-with-prefix-length

[Mahesh Jethanandani]

> On Apr 1, 2019, at 10:29 AM, Martin Bjorklund  wrote:
> 
> I know that this type is convenient, esp. if you use it for manual
> input, but I wonder if it really is good practice to squeeze two
> values into one.

Agree. The combination makes sense for CLI, but for modeling the address and 
prefix should be separate.

Mahesh Jethanandani
mjethanand...@gmail.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang next issue #46 binary encoding support

[Mahesh Jethanandani]

egotiate this. I rather say once that a
> > > binary encoding can ship an IPv6 address as type binary { length 16; }
> > > and then CBOR will simply do the right thing.
> > >
> > >
> > OK, but this would require new type names.
> > You cannot simply change some standard type to be a union with a binary
> > type.
> >
> > This forces all implementations of that type to support the binary variant.
> > That breaks old clients that worked with the version before the binary
> > variant.
> > 
> > The ripple effect on the models changing types would be non-trivial.
> > Using this union-type approach forces every protocol to support the binary
> > encoding,
> > yet base64 in a union with strings is very error-prone.
> > 
> 
> I am not proposing do change the type definitions we have. My idea was
> to have an optional additional definition for binary encodings. Here
> is an ad-hoc example (I do not like the details of the syntax, but
> perhaps this helps to understand the idea):
> 
>  typedef ipv4-address {
>type string {
>  pattern
>'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>  +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
>}
>description
>  "The ipv4-address type represents an IPv4 address in
>   dotted-quad notation.";
> 
>binary-representation {
>  type binary {
>length 4;
>  }
>  description
>"The binary representation uses as 4-byte binary string
> in network byte ordering.";
>}
>  }
> 
> The CBOR encoder (or other binary encoders) would then encode the
> value as a 4 byte binary value, the XML and JSON encoder would use the
> canonical string representation.  If the binary-representation is not
> specified, then the generic CBOR encoding rules apply. I assume that
> additional binary representation definitions will only be needed for a
> couple of types (and I might even be fine to restrict that to
> typedefs). Anyway, details need work, but if we want to support more
> efficient binary encodings, then I think we should keep the issue #46
> open.
> 
> 
> 
> OK -- this is what I had in mind but off to the side, like a deviations 
> module.
> If the client and server agree on the module containing the standard 
> extension usages
> it will not be that complex in the protocol.
> 
>   ex:binary-representation ietf-inet-types:ipv4-address {
>  ex:binary-length 4;
>  ex:binary-pattern "b0.b1.b2.b3";
>   }
> 
> I agree YANG 1.2 should have real statements instead of extensions.
> 
> 
>  
> /js
> 
> 
> Andy
> 
>  
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/ 
> <https://www.jacobs-university.de/>>
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting

[Mahesh Jethanandani]

> On Mar 29, 2019, at 11:31 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Mar 29, 2019 at 10:50:52AM -0700, Mahesh Jethanandani wrote:
>> 
>> The combination of these bullet items, and maybe other bullet items does not 
>> make clear if there was any consensus in allowing (or maybe even preventing) 
>> vendors from using a versioning system to keep track of NBC changes on other 
>> (non-latest) branches of the model. I think I heard from multiple vendors 
>> (outside of this meeting) that making NBC changes was needed on the 
>> non-latest branches, whatever IETF or other SDOs decide. Has that sentiment 
>> changed?
>> 
>> If it is the case, the split between the requirements of SDO and the vendors 
>> is inevitable.
>> 
> 
> If there is a solution that can handle multiple branches, then the
> same solution should work for SDOs that choose to use only a single
> branch. I do not see why a split is inevitable.

If a single solution works for both SDO and the vendor, that is great. And I 
think that was the point of the third bullet in the list I send.

But that does mean the requirements of SDO and the vendor community cannot be 
different. There is a strong requirement that SDOs make NBC changes only on the 
most recent version of the YANG models. In the vendor community, NBC changes 
are going to be made on non-latest branches also.

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting

[Mahesh Jethanandani]

Hi Robert,

Thanks for putting the minutes together. 

> On Mar 28, 2019, at 1:43 AM, Rob Wilton (rwilton)  wrote:
> 
> -These was agreement that IETF models should be limited to a linear 
> revision history, with changes only in the most recent revision.  It was 
> agreed that in some cases it is necessary to make NBC changes (in a new most 
> recent revision) in IETF YANG modules to fix bugs.
>  
> -There was discussion that an applicability statement could be added, 
> or some of the requirements could be split between SDO vs Vendor 
> requirements, but there did not seem to be strong consensus either for or 
> against this change.  In anything, there seemed to be a slight preference to 
> trying not to make this split.
>  
> -It was agreed that YANG should have a single versioning scheme that 
> is capable of covering both SDO requirements and vendor requirements.  There 
> was agreement that guidelines text could be used to provide guidance on how 
> IETF models should be versioned.


The combination of these bullet items, and maybe other bullet items does not 
make clear if there was any consensus in allowing (or maybe even preventing) 
vendors from using a versioning system to keep track of NBC changes on other 
(non-latest) branches of the model. I think I heard from multiple vendors 
(outside of this meeting) that making NBC changes was needed on the non-latest 
branches, whatever IETF or other SDOs decide. Has that sentiment changed?

If it is the case, the split between the requirements of SDO and the vendors is 
inevitable.

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00

[Mahesh Jethanandani]

Support.

> On Mar 25, 2019, at 9:30 PM, Kent Watsen  wrote:
> 
> This email begins a 2-week adoption poll for:
> 
> https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00 
> <https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00>
> 
> Please voice your support or objections before April 8.
> 
> Kent (and Lou and Joel)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] IPR poll on yang-versioning-reqs-02

[Mahesh Jethanandani]

I am not aware of any IPR that applies to this draft.

> On Mar 13, 2019, at 1:29 PM, Kent Watsen  wrote:
> 
> To each author and contributor listed on the "To" line.
> 
> In order to complete the Adoption poll, are you aware of any IPR that applies
> to yang-versioning-reqs-02?  Please Reply-All to *this* email and state 
> either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If "yes", has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If "yes" again, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think appropriate.
> 
> If you are listed as a document author or contributor please answer the above 
> by
> responding to this email regardless of whether or not you are aware of any 
> relevant
> IPR.  This document will not advance to the next stage until a response has 
> been
> received from each author and listed contributor.  NOTE: THIS APPLIES TO ALL
> OF YOU LISTED IN THIS MESSAGE'S TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed as 
> an author
> or contributor, we remind you of your obligations under the IETF IPR rules 
> which
> encourages you to notify the IETF if you are aware of IPR of others on an IETF
> contribution, or to refrain from participating in any contribution or 
> discussion related
> to your undisclosed IPR. For more information, please see the RFCs listed 
> above
> and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty 
> <http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty>.
> 
> Thank you,
> Kent // as co-Chair
> 

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] yang-next meeting at IETF 104?

[Mahesh Jethanandani]

Hi Kent,

I think it makes sense to have a virtual meeting before 104. 

Mahesh Jethanandani
mjethanand...@gmail.com

> On Jan 15, 2019, at 6:45 AM, Kent Watsen  wrote:
> 
> I'm interested as well.
> 
> PS: I've been too busy to setup a virtual meeting for us to finish the review 
> of the YANG-next items in the GitHub tracker.  But things are just beginning 
> to free up a little for me now.  Would folks like to have a meeting before 
> 104 to finish that review?
> 
> Kent // contributor
> 
> 
> -Original Message-
> From: netmod  on behalf of Robert Wilton 
> 
> Date: Monday, January 14, 2019 at 12:19 PM
> To: Martin Bjorklund , "a...@yumaworks.com" 
> 
> Cc: NETMOD Working Group 
> Subject: Re: [netmod] yang-next meeting at IETF 104?
> 
> I would also be interested.  During the week would also be best. Friday 
> morning could also be a possibility depending on whether there are 
> sessions scheduled.
> 
> Thanks,
> Rob
> 
> 
>> On 14/01/2019 17:10, Martin Bjorklund wrote:
>> Hi,
>> 
>> Andy Bierman  wrote:
>>> Hi,
>>> 
>>> Is there any interest in 1 or more side meetings at the next IETF to
>>> discuss the yang-next issue list, towards the goal of determining the
>>> problem space in scope for YANG 1.2?
>> I am interested in this.  I prefer a meeting during the week; my plan
>> is to arrive Sunday afternoon.
>> 
>> 
>> /martin
>> 
>>> Those of us who would need to make travel plans would appreciate it
>>> if meetings like this were scheduled ASAP instead of ALAP ;-)
>>> 
>>> 
>>> Andy
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=BfGnjYejrGjQ93xAzY1pzA9M9wXXY7rNFeWy3dKZXWc=fNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI=
>> .
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=BfGnjYejrGjQ93xAzY1pzA9M9wXXY7rNFeWy3dKZXWc=fNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI=
> 
> ___
> 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] comments on YANG versioning

[Mahesh Jethanandani]

I am wondering if we are looking at two sets of rules for the versioning system 
we come up with. One that vendors do with their "native" models to satisfy 
their customers, and the other what standard bodies follow for the models 
published by them.

For example, vendors can make feature and NBC fixes to models in releases that 
are not the latest, while standard bodies like IETF make changes in models that 
are always the latest, even as they use the same versioning system. Again, 
vendors use all the three numbers, but standard bodies use the first (major) 
and the last (patch) number.

Mahesh Jethanandani
mjethanand...@gmail.com

> On Nov 9, 2018, at 5:52 AM, Andy Bierman  wrote:
> 
> Hi,
> 
> A few comments on the netmod meeting yesterday
> 
> 1) what is a bugfix?
> It is not encouraging that the DT cannot agree on the scope of a bugfix.
> But not sure it matters if NBC updates can occur for any reason.
> IMO it is easy to define a bugfix in the IETF -- it is called an Errata.
> If an Errata is approved for a YANG module in an RFC then it is a bugfix.
> 
> 
> 2) SEMVER to the rescue?
> If every module release can be its own feature release train then the value of
> ascending numeric identifiers is greatly diminished. The (m) and (M) tags
> do not really help.  I strongly agree with the comment that cherry-picking new
> features can (and should) be done with deviations.  Updates of old
> revisions needs to be for bugfixes only.
> 
> I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
> incompatible complex numbering scheme to support something that
> should not be done anyway.
> 
> 3) Bundles and compatibility modules
> I strongly agree this solution approach is far better than treating every 
> revision
> as a separate feature release train.  I don't see how I am going to
> track the major.minor.patch for 100 different modules.  SEMVER is not
> very useful for telling if module A works with B, C, and D. Import by SEMVER
> will probably be OK at first, but become too error-prone after awhile.
> 
> 4) Automation tools
> Ad-hoc WEB pages from IANA do not cut it anymore.
> We need a way to get patch versions of modules published and usable
> by automation tools (without an RFC) with just the Errata report as a patch.
> SEMVER requires that a module be released with the change but this is not 
> that practical.
> Think how yocto works, using a base source version of a package + patches.
> (IMO we need YANG Packages, which would serve as recipes
> for a set of modules, features, annotations, patches and deviations, that 
> have been
> tested to work together.)
> 
> 5) YANG 1.2 vs Extensions
> IMO a new YANG version would be better than extensions, especially to
> fix status-stmt, import-by-revision, deviations, and add annotation,
> patch, and many other new mechanisms to help backward compatibility.
> 
> 
> Andy
> 
> ___
> 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] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Mahesh Jethanandani]

Support.

> On Oct 18, 2018, at 6:03 AM, Lou Berger  wrote:
> 
> All,
> 
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
> 
> The poll ends Oct 1.
> 
> Thanks,
> 
> Lou (and co-chairs)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Place to download Standard YANG Modules ?

[Mahesh Jethanandani]

> On Oct 11, 2018, at 8:04 AM, Martin Bjorklund  wrote:
> 
> Mahesh Jethanandani  wrote:
>> 
>> 
>>> On Oct 10, 2018, at 11:51 PM, Martin Bjorklund  wrote:
>>> 
>>> I just which there was a one-click way (or better some repo) to get
>>> all files.
>> 
>> There is. Benoit had written it, but for the life of me I cannot
>> remember what it is called.
> 
> I meant from IANA.  3rd party mirrored repos are fine, but it would be
> nice to get them directly from IANA in a simple way.

Ok. Here is the process.

You can get the entire IANA repository by doing this:

rsync -avzH rsync.iana.org <http://rsync.iana.org/>::assignments std/iana

But if you care just about the YANG models in the IANA repository, do this:

rsync -avz --delete rsync.ietf.org::iana/yang-parameters .

> 
> 
> /martin

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Place to download Standard YANG Modules ?

[Mahesh Jethanandani]

> On Oct 10, 2018, at 11:51 PM, Martin Bjorklund  wrote:
> 
> I just which there was a one-click way (or better some repo) to get
> all files.

There is. Benoit had written it, but for the life of me I cannot remember what 
it is called. Have send him a note, but he is offline till Nov.

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] [yang-doctors] Quirky YANG

[Mahesh Jethanandani]

[Adding softwire chairs, document shepherd, and AD, and moving netmod to Bcc]

Yes.

> On Oct 3, 2018, at 4:51 PM, Reshad Rahman (rrahman)  wrote:
> 
> Thanks Mahesh. So the IESG is supposed to ask for YD review at this point for 
> draft-ietf-softwire-yang?
>  
> From: Mahesh Jethanandani 
> Date: Wednesday, October 3, 2018 at 7:38 PM
> To: "Reshad Rahman (rrahman)" 
> Cc: tom petch , "netmod@ietf.org" , 
> YANG Doctors 
> Subject: Re: [yang-doctors] [netmod] Quirky YANG
>  
>   <>
> 
> 
>> On Oct 3, 2018, at 2:41 PM, Reshad Rahman (rrahman) > <mailto:rrah...@cisco.com>> wrote:
>>  
>> Are YD reviews optional for IETF YANG modules? I assumed it was mandatory.
>  
> Here is what it says on the YD page:
>  
> All YANG documents will be passed by a YANG doctor reviewer before they will 
> be approved by the IESG. The YANG doctor review must be done after the 
> Working Group Last Call and before the IETF Last Call. ADs and WG chairs 
> responsible on I-Ds that include YANG documents should ask the OPS ADs for a 
> review as soon as the document completed WGLC. Failing that request, the 
> review will be conducted during the IETF Last Call.
>  
> Mahesh Jethanandani
> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] [yang-doctors] Quirky YANG

[Mahesh Jethanandani]

> On Oct 3, 2018, at 2:41 PM, Reshad Rahman (rrahman)  wrote:
> 
> Are YD reviews optional for IETF YANG modules? I assumed it was mandatory.

Here is what it says on the YD page:

All YANG documents will be passed by a YANG doctor reviewer before they will be 
approved by the IESG. The YANG doctor review must be done after the Working 
Group Last Call and before the IETF Last Call. ADs and WG chairs responsible on 
I-Ds that include YANG documents should ask the OPS ADs for a review as soon as 
the document completed WGLC. Failing that request, the review will be conducted 
during the IETF Last Call.

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Last Call: (Network Access Control List (ACL) YANG Data Model) to Proposed Standard

[Mahesh Jethanandani]

Tom,

Here is information on Cobranet.

https://en.wikipedia.org/wiki/CobraNet <https://en.wikipedia.org/wiki/CobraNet>


> On Oct 3, 2018, at 9:33 AM, tom petch  wrote:
> 
> I thought that I had asked this before but perhaps I forgot.
> 
>   enum cobranet {
> value 34841;
> description
>   "CobraNet. Hex value of 0x";
> 
> Where can I find out abut CobraNet?  and I cannot reconcile
> value 34841;
> with
>  Hex value of 0x”;

It should say “Hex value of 0x8819”.

> 
> 
> Tom Petch
> 
> - Original Message -
> From: "The IESG" 
> To: "IETF-Announce" 
> Cc: ; ;
> ; 
> Sent: Monday, June 25, 2018 3:07 PM
> Subject: [netmod] Last Call: 
> (Network Access Control List (ACL) YANG Data Model) to Proposed Standard
> 
> 
>> 
>> The IESG has received a request from the Network Modeling WG (netmod)
> to
>> consider the following document: - 'Network Access Control List (ACL)
> YANG
>> Data Model'
>>   as Proposed Standard
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
> final
>> comments on this action. Please send substantive comments to the
>> i...@ietf.org mailing lists by 2018-07-09. Exceptionally, comments may
> be
>> sent to i...@ietf.org instead. In either case, please retain the
> beginning of
>> the Subject line to allow automated sorting.
>> 
>> Abstract
>> 
>> 
>>   This document defines a data model for Access Control List (ACL).
> An
>>   ACL is a user-ordered set of rules, used to configure the
> forwarding
>>   behavior in device.  Each rule is used to find a match on a packet,
>>   and define actions that will be performed on the packet.
>> 
>> 
>> 
>> 
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>> 
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ballot/
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

[Mahesh Jethanandani]

[Removing the resolved items]

> On Sep 28, 2018, at 9:40 AM, Benjamin Kaduk  wrote:
> 
>>> Section 1
>>> 
>>>  The match criteria allows for definition of packet headers and
>>>  metadata, all of which must be true for the match to occur.
>>> 
>>> nit: Is this missing a word like "contents”?
>> 
>> I am not sure if we are, possibly because I do not understand what you mean 
>> by “contents”.  ACL rules are written to match against packet headers and 
>> metadata. They are not written to match against the “contents” of the packet.
> 
> "definition of packet headers and metadata" sounds like something that a
> protocol designer or hardware vendor specifies; it's the values of those
> fields that a firewall device is using for its logic.

Ahh! I see what you mean. How about this?

OLD:
   The match criteria allows for definition of packet headers and
   metadata, all of which must be true for the match to occur.


NEW:
   The match criteria allows for definition of packet headers and
   metadata, the contents of which must match the definitions.

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-acl-model-19: (with COMMENT)

[Mahesh Jethanandani]

Hi Adam,

> On Sep 26, 2018, at 10:46 PM, Adam Roach  wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks to everyone who contributed their time and knowledge to this document. 
> I
> have two minor comments.
> 
> Throughout the data module, the terms "ace" and "ACE" are used 
> interchangeably.
> It would probably be good to rationalize these (I would suggest "ACE”).

I went through the draft. The only places where the term “ace” is used is to 
reference the node ‘ace’ in the model. Where it is not referencing the node, 
the model uses “ACE”. Hope that clarifies.

> 
> ---
> 
> §4.3 and 4.4:
> 
> These examples use IPv4 addresses exclusively. Please update to use IPv6 or a
> mix of IPv4 and IPv6. See 
> https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
> for additional information.

Section 4.3 has two examples, one for IPv4 and one for IPv6.

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

[Mahesh Jethanandani]

> On Sep 26, 2018, at 9:36 PM, Suresh Krishnan  wrote:
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This document is missing ACL handling for ICMPv6 (RFC4443) completely. As the
> ICMP types and codes are different for ICMP and ICMPv6 I think this model
> should be included to cover ICMPv6.

In offline discussions with Suresh, here is what we agreed I would do to 
address this DISCUSS:

- Update the rest-of-header field in ICMP grouping from ‘type uint32’ to ‘type 
binary’, as already agreed, to address Mirja’s DISCUSS. The field will be 
unbounded.
- Add a reference to RFC 4443 in the grouping.
- At this point the grouping should be able to cater to both icmpv4 and icmpv6 
match requirements.

Thanks

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

[Mahesh Jethanandani]

Hi Suresh,

Is the model usable as is? Can it be augmented for other protocols? 

I think the answer to both the questions is yes. I do not see why then can 
requests like yours not be handled as separate drafts. What is the reason to 
hold up this draft this late in the game?

Cheers.

> On Sep 26, 2018, at 10:06 PM, Suresh Krishnan  wrote:
> 
> Hi Mahesh,
>  Thanks for your quick reply. Please find comments inline.
> 
>> On Sep 27, 2018, at 12:57 AM, Mahesh Jethanandani  
>> wrote:
>> 
>> Hi Suresh,
>> 
>>> On Sep 26, 2018, at 9:36 PM, Suresh Krishnan  wrote:
>>> 
>>> Suresh Krishnan has entered the following ballot position for
>>> draft-ietf-netmod-acl-model-19: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> This document is missing ACL handling for ICMPv6 (RFC4443) completely. As 
>>> the
>>> ICMP types and codes are different for ICMP and ICMPv6 I think this model
>>> should be included to cover ICMPv6.
>> 
>> I understand that there are many protocols that fall into such a criteria. 
>> As has already been discussed, we are offering the minimum set of protocols 
>> for which there is a demand, while giving the option to extend it through 
>> augmentations of the base model.
> 
> I understand where you are coming from but ICMPv6 is not just another 
> protocol. It is a core protocol in the IPv6 protocol suite. Do you know of 
> any systems that support IPv6 acls but not support ICMPv6 there?
> 
>> 
>> Let us not boil the ocean. As it is, this draft has been in the works for 
>> more than 4 years.
> 
> This is a very clear and bounded request (i.e. not boiling the ocean). I do 
> not think this will be significant amount of work. If you do feel otherwise, 
> I will be glad to revisit my position
> 
> Regards
> Suresh

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

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

[Mahesh Jethanandani]

Hi Suresh,

> On Sep 26, 2018, at 9:36 PM, Suresh Krishnan  wrote:
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This document is missing ACL handling for ICMPv6 (RFC4443) completely. As the
> ICMP types and codes are different for ICMP and ICMPv6 I think this model
> should be included to cover ICMPv6.

I understand that there are many protocols that fall into such a criteria. As 
has already been discussed, we are offering the minimum set of protocols for 
which there is a demand, while giving the option to extend it through 
augmentations of the base model.

Let us not boil the ocean. As it is, this draft has been in the works for more 
than 4 years.

> 
> 
> 
> 

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

Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

[Mahesh Jethanandani]

Hi Alissa,

> On Sep 26, 2018, at 2:26 PM, Alissa Cooper  wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> We previously had a work item we were tracking with the IEEE leadership around
> the IEEE writing a YANG module for ethertypes. I just wanted to check that the
> IEEE is aware that this document is defining a placeholder module for
> ethertypes until such time that they define one.

They were told as much in the joint IETF-IEEE meeting.

> 
> 
> --
> COMMENT:
> --
> 
> Sec 1:
> 
> s/Policy Based Routing, Firewalls etc./policy-based routing, firewalls, etc./

Isn’t Policy Based Routing (PBR) and particular form of routing, with its own 
acronym and all? I can make the F in Firewalls, lowercase.

> 
> "The matching of filters and actions in an ACE/ACL are triggered only
>   after application/attachment of the ACL to an interface, VRF, vty/tty
>   session, QoS policy, routing protocols amongst various other config
>   attachment points.”

> 
> This is a sentence fragment.


How about this:

OLD:
   The matching of filters and actions in an ACE/ACL are triggered only
   after application/attachment of the ACL to an interface, VRF, vty/tty
   session, QoS policy, routing protocols amongst various other config
   attachment points.


NEW:
   The matching of filters and actions in an ACE/ACL are triggered only
   after the application/attachment of the ACL to an interface, VRF, vty/tty
   session, QoS policy, or routing protocols amongst various other config
   attachment points.

> 
> s/in the ACE's/in the ACEs/

Ok.

> 
> Sec 3.1:
> 
> "There are two YANG modules in the model."
> 
> Is this technically correct, given that ietf-ethertypes is also defined here?
> 
> Also, I don't think the definition of ietf-ethertypes belongs in an appendix
> under the heading "Extending ACL model examples." I can imagine that other
> modules will want to import this module and that seems like a strange place to
> put it.

That is what we could agree with IEEE on.

> 
> Sec 4.1:
> 
> For avoidance of confusion, I would suggest replacing "l2," "l3," and "l4" 
> with
> "layer2," "layer3," and "layer4," respectively.

I would object to making these changes in the model, particularly since the 
description already defines what they are.

> 
> s/Definitions of action for this ace entry/Definitions of action for this ACE
> entry/

It is referring to the node ‘ace’ defined in the module.

> 
> s/Specifies the forwarding action per ace entry/Specifies the forwarding 
> action
> per ACE entry/

Same as above.

> 
> Sec 4.2:
> 
> "This module imports definitions from Common YANG Data Types [RFC6991]
>   and references IP [RFC0791], ICMP [RFC0792], Definition of the
>   Differentiated Services Field in the IPv4 and IPv6 Headers [RFC2474],
>   The Addition of Explicit Congestion Notification (ECN) to IP
>   [RFC3168], , IPv6 Scoped Address Architecture [RFC4007], IPv6
>   Addressing Architecture [RFC4291], A Recommendation for IPv6 Address
>   Text Representation [RFC5952], IPv6 [RFC8200]."
> 
> It looks like something is missing from this list, possibly RFC 793.

Ok.

> 
> Sec 5:
> 
> In this section or elsewhere it would be nice to see a sentence noting that
> this YANG model allows the configuration of packet logging, which if used 
> would
> additionally warrant protections against unauthorized log access and a logs
> retention policy.

How about this addition to the section under list of subtrees and data nodes 
that are sensitive and vulnerable:

  /acls/acl/aces/ace/actions/logging: This node specifies ability to log
  packets that match this ace entry.  Unauthorized write access to this
  node can allow intruders to enable logging on one or many ace entries, 
  overwhelming the server in the process. Unauthorized read access of this 
node 
  can allow intruders to access logging information, which could be used to
  attack the server.

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

[Mahesh Jethanandani]

;   session, QoS policy, routing protocols amongst various other config
>   attachment points.
> 
> nit: I think the end of this list needs some clarification/termination,
> like "and routing protocols, amongst”

Ok. Will add the word ‘and’ after the comma. 

> 
> Section 3
> 
>  The
>   match criteria allows for definition of packet headers or metadata,
>   if supported by the vendor.  [...]
> 
> (same nit as above re "contents")
> 
>   Metadata matching applies to fields associated with the packet, but
>   not in the packet header such as input interface, packet length, or
>   source or destination prefix length.  The actions can be any sort of
> 
> nit: comma after "not in the packet header”

Ok.

> 
> Section 4.1
> 
> nit: The feature match-on-udp and -icmp descriptions should probably use
> the plural "headers" to match the other features' descriptions.

Ok.

> 
> The mixed- features seem to implicitly assume that if features X and
> Y are individually supported, then the combination is also supported.  I
> could imagine that there might exist hardware for which that assumption is
> not true, but don't know if there actually is any such hardware or it's
> common enough to be worth caring about here.

The individual feature statements exist to allow for the server to pick what 
the hardware supports. If the hardware does not support the combination, the 
server will choose not to advertise the feature statements for the combinations.

> 
>   grouping acl-counters {
> leaf matched-packets {
>  [...]
>  An implementation should provide this counter on a
>  per-interface per-ACL-entry if possible.
> 
> nit: missing "basis"?  (Also in subsequent instances.)

Ok.

> 
> Section A.1
> 
> It's unclear that using a...@newco.com (in particular, the @newco.com part)
> in an example is reasonable; @newco.example would be better.

I do not know if a contact e-mail address, in an example of a YANG model, is 
significant.

Thanks.

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

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] Opsdir telechat review of draft-ietf-netmod-acl-model-19

[Mahesh Jethanandani]

> On Sep 25, 2018, at 12:32 PM, Joe Clarke  wrote:
> 
> Reviewer: Joe Clarke
> Review result: Has Nits
> 
> I have been assigned to review this document on behalf of the ops 
> directorate. 
> This document defines a YANG model for configuring access control lists (ACLs)
> as well as other modules for protocol data types and ether types.  Related to
> those, it requests IANA actions to register the modules.
> 
> This document is ready, and I only found a few nits in it.
> 
> Section 1:
> 
> s/criteria allows/criteria allow/ as criteria is plural
> 
> s/criteria is/criteria are/

Ok.

> 
> ===
> 
> Section 3:
> 
> s/criteria allows/criteria allows/

You mean

s/criteria allows/criteria allow/

I see one more (in Section 4.2) that I will correct also.

> 
> ===
> 
> Section 7:
> 
> s/together to created a/together to create a/

Ok.

> 
> ===
> 
> Section A.3:
> 
> Why is this module not yang-version 1.1 like the other two?

Ok.

> 
> 
> ___
> 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] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

[Mahesh Jethanandani]

Hi Mirja,

See responses inline.

> On Sep 25, 2018, at 2:32 AM, Mirja Kuehlewind (IETF)  
> wrote:
> 
> Hi Mahesh,
> 
> please see below.
> 
>> Am 25.09.2018 um 00:56 schrieb Mahesh Jethanandani :
>> 
>> 
>> 
>>> On Sep 21, 2018, at 6:47 AM, Mirja Kühlewind  wrote:
>>> 
>>> Mirja Kühlewind has entered the following ballot position for
>>> draft-ietf-netmod-acl-model-19: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> 1) The tcp options element is type uint32, however, the option field in the 
>>> TCP
>>> header can be up to 40 bytes.
>> 
>> You are right that the options field can be up to 40 bytes long.
>> 
>> To the WG - We have two options in front of us. Take the field out 
>> completely or change the type to binary, and add a ‘length’ restriction of 
>> 40. Unless there is a objection, we will go with the latter option.
> 
> Not sure what exactly you mean but change the type to binary and add a length 
> restriction but I’ll leave it to you to have the appropriate change.

Ok.

> 
>> 
>>> 
>>> 2) Why are only TCP and UDP supported? What's about SCTP and DCCP?
>> 
>> There has been no requirement to support either of those protocols. Support 
>> for those protocols can be added as augmentations to the base model in the 
>> future if such a need arises.
> 
> That’s do bad. However, the document must at least say that it’s scope is 
> restricted to TCP and UDP only and it would also be nice to reason why that 
> restriction is and what would need to be done to extend it in future.

To the contrary. The model is not restricted to TCP and UDP. In Section 2, the 
document states that:

   ACL implementations in every device may vary greatly in terms of the
   filter constructs and actions that they support.  Therefore this
   draft proposes a model that can be augmented by standard extensions
   and vendor proprietary models.


It is a different matter that it has chosen not to support SCTP and DCCP. That 
is because implementations today have not felt the market need to add support 
for those protocols. But that does not prevent anyone from adding support for 
them.

As far as an example for how the model can be extended in the future, see 
Appendix A - Extending ACL model examples.

> 
>> 
>>> 
>>> 3) The icmp rest-of-header can also be larger than 4 bytes but the type is
>>> uint32 again.
>> 
>> You are right that the rest-of-header can be more than 4 bytes, but in 
>> reality we have not had a requirement to support more than 4 bytes. 
>> 
>> To the WG - We will give it the same treatment as above - two options. Take 
>> it out completely, or change this to binary also. The only difference is 
>> that there does not seem to be a length restriction on the size of the 
>> field, so the field will be left unbounded. Unless there is a objection, we 
>> will go with the conversion to binary option.
> 
> Again, leaving it to you to apply the appropriate fix.

Ok.

Thanks.

> 
> Mirja
> 
> 
> 
>> 
>> Cheers.

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

Re: [netmod] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

[Mahesh Jethanandani]

> On Sep 21, 2018, at 6:47 AM, Mirja Kühlewind  wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> 1) The tcp options element is type uint32, however, the option field in the 
> TCP
> header can be up to 40 bytes.

You are right that the options field can be up to 40 bytes long.

To the WG - We have two options in front of us. Take the field out completely 
or change the type to binary, and add a ‘length’ restriction of 40. Unless 
there is a objection, we will go with the latter option.

> 
> 2) Why are only TCP and UDP supported? What's about SCTP and DCCP?

There has been no requirement to support either of those protocols. Support for 
those protocols can be added as augmentations to the base model in the future 
if such a need arises.

> 
> 3) The icmp rest-of-header can also be larger than 4 bytes but the type is
> uint32 again.

You are right that the rest-of-header can be more than 4 bytes, but in reality 
we have not had a requirement to support more than 4 bytes. 

To the WG - We will give it the same treatment as above - two options. Take it 
out completely, or change this to binary also. The only difference is that 
there does not seem to be a length restriction on the size of the field, so the 
field will be left unbounded. Unless there is a objection, we will go with the 
conversion to binary option.

Cheers.

> 
> 
> 
> 

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

Re: [netmod] "iana" in yang modules' name/namespace/prefix

[Mahesh Jethanandani]

Sent from my iPhone

> On Jul 20, 2018, at 10:40 AM, Juergen Schoenwaelder 
>  wrote:
> 
>> On Fri, Jul 20, 2018 at 03:45:47PM +0200, Martin Vigoureux wrote:
>> 
>> As part of a recent IESG review (of draft-bfd-yang) a point came up on the
>> use of "iana" in yang modules' name/namespace/prefix.
>> This is typically used in the case where the module refers to an IANA
>> maintained registry. However, the point raised was that the name of the
>> registry operator might not always be IANA, and that using that name might
>> not put modules on the most stable deployment footing under all possible
>> circumstances.
>> 
>> On top of that, as far as I can tell, the use of "iana" is an undocumented
>> convention.
>> 
>> So, I wanted to collect views:
>> on whether a convention should be documented,
>> and, with regards to the point raised in IESG, on whether that keyword
>> should be changed going forward. In that context, what about "reg" (for
>> registry) or "regop" (for registry operator)? Other proposals are welcome.
> 
> iana- has the advantage that everybody knows which registry is meant.
> Using registry- is perhaps more flexible in case IANA registry gets
> renamed but it leaves is much more open where the module is
> maintained. The first part of a module name is supposed to identify an
> organization. draft-ietf-netmod-rfc6087bis-20.txt (RFC editor queue)
> says:
> 
>   It is suggested that a stable prefix be selected representing the
>   entire organization.  All normative YANG modules published by the
>   IETF MUST begin with the prefix "ietf-".  Another standards
>   organization, such as the IEEE, might use the prefix "ieee-" for all
>   YANG modules.
> 
> Concerning documentation, perhaps we could change the above to this:
> 
>   It is suggested that a stable prefix be selected representing the
>   entire organization.  All normative YANG modules published by the
>   IETF MUST begin with the prefix "ietf-".  Another standards
>   organization, such as the IEEE, might use the prefix "ieee-" for all
>   YANG modules. YANG modules maintained by IANA for the IETF SHOULD
>   begin with the prefix "iana-".

+1

I agree that the prefix suggests the organization responsible for maintaining 
the model, something reg- or registry- does not. Two more examples that already 
exist are mef- and etsi-. I understand there is the possibility that that 
prefix changes, but we then pick a new prefix, if we know what it might be. 

> 
> /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

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

Re: [netmod] IPR call on draft-ietf-netmod-acl-model-18

[Mahesh Jethanandani]

No. I am not aware of any IPR that applies to this draft.

Thanks.

> On Apr 25, 2018, at 4:16 PM, Kent Watsen <kwat...@juniper.net> wrote:
> 
> Authors, Contributors, WG,
> 
> As part of Shepherd write-up for the acl-model draft, we need to ensure that 
> all IPR has been declared.  There was an IPR-call before, when there was a 
> different set of authors involved, but not since, so it seems prudent to do 
> another call now. 
> 
> Are you aware of any IPR that applies to draft identified above?
> 
> 
> Please state either:
>   "No, I'm not aware of any IPR that applies to this draft"
> or
>   "Yes, I'm aware of IPR that applies to this draft"
> 
> 
> If yes, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state
> either:
>   "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
>   "No, the IPR has not been disclosed"
> 
> If no, please provide any additional details you think appropriate.
> 
> 
> If you are listed as a document author or contributor, please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under the
> IETF IPR rules which encourages you to notify the IETF if you are aware
> of IPR of others on an IETF contribution, or to refrain from participating
> in any contribution or discussion related to your undisclosed IPR. For
> more information, please see the RFCs listed above and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> 
> Kent // document shepherd and co-chair
> 
> 
> PS: Please include all listed in the headers of this message in your response.
> 
> 

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] IPR call on draft-ietf-netmod-acl-model-18

[Mahesh Jethanandani]

No. I am not aware of any IPR that applies to this draft.

Thanks.

> On Apr 25, 2018, at 4:16 PM, Kent Watsen <kwat...@juniper.net> wrote:
> 
> Authors, Contributors, WG,
> 
> As part of Shepherd write-up for the acl-model draft, we need to ensure that 
> all IPR has been declared.  There was an IPR-call before, when there was a 
> different set of authors involved, but not since, so it seems prudent to do 
> another call now. 
> 
> Are you aware of any IPR that applies to draft identified above?
> 
> 
> Please state either:
>   "No, I'm not aware of any IPR that applies to this draft"
> or
>   "Yes, I'm aware of IPR that applies to this draft"
> 
> 
> If yes, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state
> either:
>   "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
>   "No, the IPR has not been disclosed"
> 
> If no, please provide any additional details you think appropriate.
> 
> 
> If you are listed as a document author or contributor, please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under the
> IETF IPR rules which encourages you to notify the IETF if you are aware
> of IPR of others on an IETF contribution, or to refrain from participating
> in any contribution or discussion related to your undisclosed IPR. For
> more information, please see the RFCs listed above and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> 
> Kent // document shepherd and co-chair
> 
> 
> PS: Please include all listed in the headers of this message in your response.
> 
> 

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] An abundant amount of IANA if types...

[Mahesh Jethanandani]

 contrary, I think it is the 
> cleanest
> available solution to this conformance specification problem.
> 
> Vendors not shipping proper deviations are essentially telling their
> customers that they have not yet understood model driven management.
> We need to change the mindset here instead of polluting our data
> models with hundreds or thousands of fine grained 'features'.
> I agree that zillions of features aren't nice but it seems to be the only
> solution that we currently have for modules of the iana-if-type style.
> 
> Having an bulky set of identity values, most of which are of no interest, is 
> IMO
> much worse and could also be a security issue if implementors aren't careful
> enough.
> I'm not sure there is a security concern here, but a long list where most of 
> the values are cruft doesn't really seem to help anyone.  It also makes it 
> harder to know which is the right type to use.  E.g. will everyone know that 
> they should use "ethernetCsmacd" rather than "gigabitEthernet" for an optical 
> GE interface that doesn't actually use CSMA/CD ...
> 
> Thanks,
> Rob
> 
> 
> 
> Lada
> 
> /js
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

[Mahesh Jethanandani]

> On Mar 14, 2018, at 10:42 AM, Kent Watsen <kwat...@juniper.net> wrote:
> 
> Hi Mahesh,  please look for <> below.
>  
> All, please take a look at the question around renaming the "access-lists" 
> container.
>  
> Thanks,
> Kent
>  
>  
>  
> On 3/13/18, 9:46 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com 
> <mailto:mjethanand...@gmail.com>> wrote:
>  
>  
> 
> 
>> On Mar 13, 2018, at 3:23 PM, Kent Watsen <kwat...@juniper.net 
>> <mailto:kwat...@juniper.net>> wrote:
>>  
>> Hi Mahesh,
>>  
>> Please look for  below.
>>  
>> Thanks,
>> Kent
>>  
>>  
>> On 3/8/18, 7:40 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com 
>> <mailto:mjethanand...@gmail.com>> wrote:
>>  
>> Kent,
>> 
>> 
>> 
>>> On Mar 7, 2018, at 1:55 PM, Kent Watsen <kwat...@juniper.net 
>>> <mailto:kwat...@juniper.net>> wrote:
>>>  
>>> [To all those that said this draft was ready, really?]
>>> 
>>> 
>>> Hi Mahesh,
>>> 
>>> Thanks for the update.  I found some more issues.  Some must be fixed, 
>>> others are nits, and might be caught by the RFC Editor.  But I think
>>> that it's embarrassing to receive comments for such things from the 
>>> IESG, as is recently the case for the syslog draft, so please see 
>>> what you can do.
>>> 
>>> Thanks,
>>> Kent
>>> 
>>> 
>>> From Idnits:
>>> 
>>>  ** There are 6 instances of too long lines in the document, the longest one
>>> being 7 characters in excess of 72.
>>  
>> Hmm. The idnits at submission time did not complain. Will apply the new 
>> script that you provided to make sure I wrap them around.
>> 
>> 
>> 
>>> 
>>>  You wrote before that it was "Fixed", but it's still here?  Note: "**" is
>>>  an error (idnits label)
>>> 
>>>  -- The document has examples using IPv4 documentation addresses according
>>> to RFC6890, but does not use any IPv6 documentation addresses.  Maybe
>>> there should be IPv6 examples, too?
>>> 
>>>  I don't feel strongly about this, but if it's easy enough to do...
>>> 
>>> In the Abstract:
>>>  - I think the word "an" is missing (e.g., an ACL)
>>  
>> Added.
>> 
>> 
>> 
>>> 
>>> In the Introduction:
>>>  - should "ordered-by-user" be "ordered-by user" to avoid confusion, or 
>>> perhaps say it another way?
>>  
>> How about this in both the Abstract and the Introduction.
>>  
>> OLD:
>> ACL is a ordered-by-user set of rules
>>  
>> NEW:
>> An ACL is a set of rules, in an order set by the user
>>  
>> or how about "An ACL is a user-ordered set of rules”?
>  
> Ok.
> 
> 
>> 
>> 
>>  
>>>  - what does "a tuple of" mean?  Can this be restated?
>>  
>> How about this?
>>  
>> OLD:
>> The match criteria consist of a tuple of packet header match criteria and 
>> can have metadata match criteria as well.
>>  
>> NEW:
>> The match criteria consist of packet header matches, and or or metadata as 
>> described below:
>>  
>> or how about "The match criteria can be a multiplicity of criteria, 
>> all of which must be true for the match to occur.   The match criteria may 
>> match against values in the packet header or against vendor-specific 
>> metadata about the packet."?   - or something in between?
>  
> Or simply as:
>  
> “The match criteria allows for definition of packet headers and metadata, all 
> of which must be true for the match to occur."
> 
> <> okay
>>  
>>  
>>  
>>>  - s/In case vendor supports it/In case a vendor supports it/ ?
>>  
>> Ok.
>> 
>> 
>> 
>>>  - "The list of X is endless depending on...".  Is "endless" the right 
>>> word, perhaps restate?
>> OLD:
>> The list of potential actions is endless
>>  
>> NEW:
>> The list of potential actions is limitless
>>  
>>  or maybe "unbounded”?
>  
> Ok.
> 
> 
>>  
>>  
>>>  - same sentence as above, should "networked devices" be "network" or 
>>> "networking" devices?
>>  
>> Will change “networked devices” to “networking device

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

[Mahesh Jethanandani]

> On Mar 14, 2018, at 8:28 AM, Eliot Lear <l...@cisco.com> wrote:
> 
> Hi Mahesh,
> 
> Just one point.
> 
> On 13.03.18 18:46, Mahesh Jethanandani wrote:
>>> or how about "The match criteria can be a multiplicity of criteria, 
>>> all of which must be true for the match to occur.   The match criteria may 
>>> match against values in the packet header or against vendor-specific 
>>> metadata about the packet."?   - or something in between?
>> 
>> Or simply as:
>> 
>> “The match criteria allows for definition of packet headers and metadata, 
>> all of which must be true for the match to occur."
> 
> So long as we make clear what the null set means.  To me, that's "match 
> everything”.

The description under the ‘matches’ container says:

If no matches are defined in a particular container,
then any packet will match that container. If no
        matches are specified at all in an ACE, then any
packet will match the ACE.


> 
> Eliot
> 

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

[Mahesh Jethanandani]

> On Mar 13, 2018, at 3:23 PM, Kent Watsen <kwat...@juniper.net> wrote:
> 
> Hi Mahesh,
>  
> Please look for  below.
>  
> Thanks,
> Kent
>  
>  
> On 3/8/18, 7:40 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com 
> <mailto:mjethanand...@gmail.com>> wrote:
>  
> Kent,
> 
> 
>> On Mar 7, 2018, at 1:55 PM, Kent Watsen <kwat...@juniper.net 
>> <mailto:kwat...@juniper.net>> wrote:
>>  
>> [To all those that said this draft was ready, really?]
>> 
>> 
>> Hi Mahesh,
>> 
>> Thanks for the update.  I found some more issues.  Some must be fixed, 
>> others are nits, and might be caught by the RFC Editor.  But I think
>> that it's embarrassing to receive comments for such things from the 
>> IESG, as is recently the case for the syslog draft, so please see 
>> what you can do.
>> 
>> Thanks,
>> Kent
>> 
>> 
>> From Idnits:
>> 
>>  ** There are 6 instances of too long lines in the document, the longest one
>> being 7 characters in excess of 72.
>  
> Hmm. The idnits at submission time did not complain. Will apply the new 
> script that you provided to make sure I wrap them around.
> 
> 
>> 
>>  You wrote before that it was "Fixed", but it's still here?  Note: "**" is
>>  an error (idnits label)
>> 
>>  -- The document has examples using IPv4 documentation addresses according
>> to RFC6890, but does not use any IPv6 documentation addresses.  Maybe
>> there should be IPv6 examples, too?
>> 
>>  I don't feel strongly about this, but if it's easy enough to do...
>> 
>> In the Abstract:
>>  - I think the word "an" is missing (e.g., an ACL)
>  
> Added.
> 
> 
>> 
>> In the Introduction:
>>  - should "ordered-by-user" be "ordered-by user" to avoid confusion, or 
>> perhaps say it another way?
>  
> How about this in both the Abstract and the Introduction.
>  
> OLD:
> ACL is a ordered-by-user set of rules
>  
> NEW:
> An ACL is a set of rules, in an order set by the user
>  
> or how about "An ACL is a user-ordered set of rules”?

Ok.

> 
>  
>>  - what does "a tuple of" mean?  Can this be restated?
>  
> How about this?
>  
> OLD:
> The match criteria consist of a tuple of packet header match criteria and can 
> have metadata match criteria as well.
>  
> NEW:
> The match criteria consist of packet header matches, and or or metadata as 
> described below:
>  
> or how about "The match criteria can be a multiplicity of criteria, all 
> of which must be true for the match to occur.   The match criteria may match 
> against values in the packet header or against vendor-specific metadata about 
> the packet."?   - or something in between?

Or simply as:

“The match criteria allows for definition of packet headers and metadata, all 
of which must be true for the match to occur."

>  
>  
>  
>>  - s/In case vendor supports it/In case a vendor supports it/ ?
>  
> Ok.
> 
> 
>>  - "The list of X is endless depending on...".  Is "endless" the right word, 
>> perhaps restate?
> OLD:
> The list of potential actions is endless
>  
> NEW:
> The list of potential actions is limitless
>  
>  or maybe "unbounded”?

Ok.

>  
>  
>>  - same sentence as above, should "networked devices" be "network" or 
>> "networking" devices?
>  
> Will change “networked devices” to “networking devices”.
> 
> 
>> 
>> In Section 3:
>>  - "A network system usually have a list of ACLs"  (s/system/systems/ or 
>> s/have/has/?)
>  
> s/have/has/.
> 
> 
>>  - "The match criteria consist of packet header matching" - is consist the 
>> right word?
>  
> How would you restate it? (After I have s/consist/consists/)
>  
>  see above (my comment before last, it is the same sentence, right?)

Once we agree on the above comment, I will replicate it.

> 
> 
>>  - "It as also possible for ACE to match on metadata"  s/as/is/ and s/ACE/an 
>> ACE/
>  
> Ok
> 
> 
>>  - "When applied to interfaces of a networked device, the ACL is applied in 
>> a direction
>> which indicates if it should be applied to packet entering (input) or 
>> leaving the
>> device (output)."  - restate to talk about "ingress" and "egress”?
>  
> How about:
>  
> When applied to interfaces of a networked device, the ACL is applied in a 
> direct

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

[Mahesh Jethanandani]

CL types 
that might match on a combination of ethernet and IPv4 headers etc.

>  Separately, s/ACL/an ACL/?

Ok.

>  - A number of features read "Device can support..." - s/Device/The device/?

Ok.

>  - "It can have one or more Access Control Lists" - lists should be singular.

Really? English grammar says that if a sentence has both a singular and a 
plural, the one nearest to the subject is the one you select.

>  - "An Access Control List(ACL)" - put a space before (ACL)

Ok.

>  - " Indicates the primary intended" - here's that word "primary" again...
>  - s/a list of access-list-entries(ACE)/ a list of access-list-entry nodes 
> (ACE)/?

Ok.

>  - s/List of access list entries(ACE)/List of access list entry nodes (ACE)/?
>  - there is more than one instance of this in the model

Fixed.

>  - "../../../../type" - still some long relative XPaths

Fixed.

>  - " or referring to a group of source ports" - this isn't there yet.  I 
> think you
>want to say something like "this is a choice so as to support future 'case'
>statements, such as one enabling a group of source ports to be referenced”

How about:

Choice of source port definition using range/operator or referring to a group 
of source ports, to be added as a future 'case' statement.

>  - ditto for "or referring to a group of destination ports."
>  - ditto on both of the above for the "udp" container
>  - is it possible for both "egress-interface" and "ingress-interface" leafs 
> to 
>be specified at the same time?  - if not, should there a 'must' statement 
> to
>prevent that possibility? - or an explanation for what happens if it 
> occurs?

Let me discuss this with my co-authors.

>  - s/The ACL's applied/The ACLs applied/   (this happens more than once in 
> model)

Fixed.

> 
> In Section 4.2:
>  - references them by "uses" --> references them by 'uses' statements  ???

Ok.

>  - not all your 'reference' statements have the title of the referenced 
> document.

Fixed.

>  - "then the datagram must be destroyed" - s/destroyed/dropped/?

Ok.

>  - "or referring to a group of ..."  - same comments as for previous module
>  - "ece" is missing a 'reference' statement?  - 

Added.

>  - "Indicates that the Urgent pointer field is significant" - urgent is
>capitalized, but there's no context as for why.  Perhaps missing a
>reference statement too?

Added a reference statement.

>  - in "window-size" leaf description, remove parentheses

Ok.

> 
> In Section 4.3:
>  - the text says that it drops traffic from X to Y, but the example seems to 
> do
>the reverse.

Fixed.

> 
> In Section 4.4:
>  - The "With the follow XML example:"  "This represents..." is 
>difficult to read.  How about just having "The following XML example ...:”?

Fixed.

>  - does the second example provide any value of the first? - seems the same 
> to me…

Will change the example.

>  - seems like example 3 could also be expressed as 
> "21",
>right?  - the text at the beginning of the section says this construct is
>possible, but there is no example for it.  Maybe this makes a better ex #2?

Have changed the language in the beginning of the section to say:

"When only a port is present, it represents a port, with the operator 
specifying the range."

That is because, it now a choice between specifying a range or specifying a 
single port with an operator.

> 
> In all your YANG modules:
>  - replace "NETMOD (NETCONF Data Modeling Language)" with "NETMOD (Network 
>Modeling) Working Group”

Ok.

> 
> In Section ??:
>  In the examples, why did you add the ""
>  line and the "config" element?  - the examples validate equally well when
>  these are removed.

The examples can then be cut and pasted into any client such as ncclient which 
takes an entire .

> 
> In Section 6:
>  - s/three YANG module/three YANG modules/

Fixed.

> 
> In Section 6.1:
>  - The first paragraph says "three URI", but it should be "three URIs”

Fixed.

> 
> In Section A.1:
>  - "The following figure is the tree structure" - should say "tree diagram" 
> and
>should reference the tree-diagrams draft, or else have a draft-wide "Tree
>    Diagram Notation" section in the Introduction.

Added a section in the Introduction.

>  - s/In other example/In another example/?
>  - s/with new choice of actions/with a new choice of actions/?

Both fixed.

> 
> In Section A.3;
>  - some 'reference' statements are missing titles

Added.

>  - some 'de

Re: [netmod] choice/case in tree diagrams

[Mahesh Jethanandani]

> On Mar 5, 2018, at 6:27 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> 
> Martin Bjorklund <m...@tail-f.com <mailto:m...@tail-f.com>> wrote:
>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
>>> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
>>>>> 
>>>>> So it seems the running code got it right. ;-)
>>>> 
>>>> As the author of that code, I think that was purely by accident...
>>>> 
>>>> But I'm not convinced it is the correct solution.  We have one example
>>>> in the other thread where someone was confused by the "rw" flag and
>>>> thought that it implied that the node would be present in the data
>>>> tree.
>>>> 
>>> 
>>> So what does rw mean?
>>> 
>>> (i)  The schema node has a rw property.
>>> (ii) The schema node can be instantiated and the instantiated data node
>>> has a rw property.
>>> 
>>> I think it is difficult to have both at the same time. If the tree is
>>> a representation of schema nodes, then (i) seems to make more
>>> sense. That said, the explanation in 2.6 is somewhat vague since it
>>> says 'data' and not 'nodes' (like everywhere else):
>>> 
>>> OLD:
>>> 
>>>is one of:
>>> rw  for configuration data
>>> ro  for non-configuration data, output parameters to rpcs
>>> and actions, and notification parameters
>>> 
>>> NEW:
>>> 
>>>is one of:
>>> rw  for configuration data nodes
>>> ro  for non-configuration data nodes, output parameters to rpcs
>>> and actions, and notification parameters
>> 
>> I think this is ok.  But that means that we also have to add:
>> 
>>   --  for a choice or case node
>> 
>> But in order to be consistent, we should probably have:
>> 
>>   --  for a choice, case, input or output node
> 
> Whoops, it shouldn't be "--".  Somehow we should say that no flags are
> used for choice,case,input,output.

I would agree, as having choice/case statements represented as schema nodes is 
not only confusing in the tree diagram, but also confusing when constructing an 
example. The tree diagram represents it as a node, where one would put it in 
the example, but validation complained about it (not being a node).

> 
> 
> /martin
> 
> 
>> 
>> 
>> This means that the correct tree syntax for choice and case will be:
>> 
>> +-- (subnet)?
>>+-- :(prefix-length)
>>|  +--rw prefix-length?   uint8
>>+-- :(netmask)
>>   +--rw netmask? yang:dotted-quad
>> 
>> 
>> /martin
>> 
>> 
>>> The document (as far as I searched for it) does not clearly say that
>>> 'node' means 'schema node'. In hindsight, it might have been useful to
>>> explicitely import terminology from RFC 7950 and to use it carefully
>>> (RFC 7950 has 'schema node' and 'data node' but here we largely talk
>>> about 'nodes' - and my assumption is that this means 'schema nodes'.)
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

[Mahesh Jethanandani]

This version of the draft addresses comments raised during LC, shepherd review 
and other comments received during that period.

> On Mar 3, 2018, at 2:13 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Network Modeling WG of the IETF.
> 
>Title   : Network Access Control List (ACL) YANG Data Model
>    Authors     : Mahesh Jethanandani
>  Lisa Huang
>  Sonal Agarwal
>  Dana Blair
>   Filename: draft-ietf-netmod-acl-model-17.txt
>   Pages   : 57
>   Date: 2018-03-03
> 
> Abstract:
>   This document defines a data model for Access Control List (ACL).
>   ACL is a ordered-by-user set of rules, used to configure the
>   forwarding behavior in device.  Each rule is used to find a match on
>   a packet, and define actions that will be performed on the packet.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-17
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-17
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-17
> 
> 
> 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/
> 
> _______
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] ACL draft issues found during shepherd writeup

[Mahesh Jethanandani]

Guys,

Before we start proposing whole set of changes, please verify that the model is 
not doing what it was supposed to. The only difference between the changes 
below and what is in the model is that instead of it being a repeat for source 
and destination ports, the code below exists as a grouping.

Cheers.

> On Feb 27, 2018, at 3:01 AM, Einar Nilsen-Nygaard (einarnn) 
> <eina...@cisco.com> wrote:
> 
> What Kristian and I discussed, what Sonal and I had discussed, and what I 
> thought we had accepted as a proposed change was something like:
> 
> choice source-port-range-or-operator {
>   case range {
> leaf source-port-lower {
>   type inet:port-number;
>   must ". <= ../source-port-upper" {
> error-message
>   "The source-port-lower must be less than or equal to
>source-port-upper";
>   }
>   mandatory true;
>   description
> "Lower boundary for port.";
> }
> leaf source-port-upper {
>   type inet:port-number;
>   mandatory true;
>   description
> "Lower boundary for port.";
> }
>   }
>   case operator {
> leaf source-operator {
>   type operator;
>   mandatory true;
> }
> leaf source-port {
>   type inet:port-number;
>   mandatory true;
>   description
> "Port value to match.";
> }
>   }
> }
> 
> …and with the same pattern for the destination. The type “operator” was 
> defined as:
> 
>   typedef operator {
> type enumeration {
>   enum lte {
> description
>   "Less than or equal to.";
>   }
>   enum gte {
> description
>   "Greater than or equal to.";
>   }
>   enum eq {
> description
>   "Equal to.";
>   }
>   enum neq {
> description
>   "Not equal to.";
>   }
> }
> 
> Cheers,
> 
> Einar
> 
> 
>> On 27 Feb 2018, at 09:20, Eliot Lear <l...@cisco.com 
>> <mailto:l...@cisco.com>> wrote:
>> 
>> This edit doesn't seem correct to me because now we have a choice with a 
>> single case, with range having been removed.  Can we please revert and 
>> proceed?
>> 
>> On 26.02.18 20:24, Mahesh Jethanandani wrote:
>>> A pull request to address LC, shepherd, this and the other comments, 
>>> including derived-from(), can be reviewed here:
>>> 
>>> https://github.com/netmod-wg/acl-model/pull/24 
>>> <https://github.com/netmod-wg/acl-model/pull/24>
>>> 
>>> Thanks.
>>> 
>>>> On Feb 26, 2018, at 12:15 AM, Eliot Lear <l...@cisco.com 
>>>> <mailto:l...@cisco.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 26.02.18 06:55, Mahesh Jethanandani wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  PS: And this is not a shepherd directive, but I found the whole 
>>>>>>>  "source-port-range-or-operator" syntax clumsy.  I'm surprised
>>>>>>>  it didn't look something like:
>>>>>>> 
>>>>>>>  OLD
>>>>>>>
>>>>>>>   
>>>>>>> 
>>>>>>>   16384
>>>>>>>   65535
>>>>>>> 
>>>>>>>   
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>  eq
>>>>>>>  21
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> 
>>>>>>>  NEW
>>>>>>> 
>>>>>>>
>>>>>>>      
>>>>>>>16384
>>>>>>>65535
>>>>>>>  
>>>>>>>
>>>>>>> 
>>>>>>>
>>&g

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Mahesh Jethanandani]

This officially closes the LC on YANG Library bis draft. I know that separately 
there has been a YANG Doctors review of this draft.

Authors, please post an updated draft addressing the comments received during 
LC and other reviews on the document. I will then do a shepherd’s writeup and 
send it for publication.

Thanks.

Mahesh //as shepherd

> On Feb 16, 2018, at 8:04 AM, Robert Wilton <rwil...@cisco.com> wrote:
> 
> 
> 
> On 16/02/2018 15:33, Ladislav Lhotka wrote:
>> Robert Wilton <rwil...@cisco.com> writes:
>> 
>>> Hi Lada,
>>> 
>>> 
>>> On 16/02/2018 09:06, Ladislav Lhotka wrote:
>>>> Robert Wilton <rwil...@cisco.com> writes:
>>>> 
>>>>> I should add, as a contributor, I have read this document and think that
>>>>> is ready for advancement.
>>>>> 
>>>>> I have three minor comments:
>>>>> 
>>>>> 1) module "feature" in YANG library is a leaf-list, but currently it is
>>>>> a list in YANG libary bis. I suspect that this is due to one of the
>>>>> incarnations when it contained additional information.  I think that we
>>>>> should revert it back to being a leaf list for consistency.
>>>>> 
>>>>> 2) Lada recommended that module "deviation" be made a leaf-list. I also
>>>>> support changing this for consistency with "feature" above, but don't
>>>>> feel too strongly on this one.
>>>> I agree to have both as leaf-lists.
>>>> 
>>>>> 3) I think the "modules" list is also allowed to included modules that
>>>>> don't actually contain any nodes that require implementation.  Hence, it
>>>>> might be useful of the "modules" description statement explicitly stated
>>>>> this.  I.e. perhaps something like:
>>>>> 
>>>>> "This list may contain modules that do not contain any schema nodes that
>>>>> require implementation.  For example, it could contain a module that
>>>>> only defines types and not any data nodes, RPCs, actions, notifications,
>>>>> or deviations."
>>>> Hmm, such modules belong to the other list "import-only-modules", don't
>>>> they?
>>> So my reasoning is that either is valid.
>>> 
>>> I.e. a module being listed under "modules" means that it implements all
>>> data nodes, RPCs, actions, notifications, deviations, etc.  If a module
>>> doesn't contain any data nodes, RPCs, actions, notifications,
>>> deviations, etc then it is trivially implemented :-)
>> OK, so if a module contains only groupings and typedefs, it can appear
>> either in "modules" or in "import-only-modules", and the effect is the
>> same, right?
> Yes.
> 
>> 
>> This sounds reasonable.
>> 
>>> As an aside, RFC 7950 states in 5.6.5:
>>> 
>>>   A server implements a module if it implements the module's data
>>> nodes, RPCs, actions, notifications, and deviations.
>>> 
>>> 
>>> I wonder whether identities shouldn't also be on this list, since
>>> section 9.10.2 states:
>> Yes, and extensions as well.
>> 
>> Lada
> Thanks,
> Rob
> 
>> 
>>> On a particular server, the valid values are further restricted
>>> to the set of identities defined in the modules implemented by the server.
>>> 
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
>>>> Lada
>>>> 
>>>>> Thanks,
>>>>> Rob
>>>>> 
>>>>> 
>>>>> On 02/02/2018 13:51, Kent Watsen wrote:
>>>>>> As co-author, I am not aware of any IPR related to this document.
>>>>>> 
>>>>>> As a contributor, I have read this document and think that it is ready
>>>>>> for advancement.
>>>>>> 
>>>>>> Kent
>>>>>> 
>>>>>> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
>>>>>> <netconf-boun...@ietf.org <mailto:netconf-boun...@ietf.org> on behalf
>>>>>> of rwil...@cisco.com <mailto:rwil...@cisco.com>> wrote:
>>>>>> 
>>>>>> I am not aware of any IPR related to this document.
>>>>>> 
>>>>>> Thanks,
>>>>>> Rob
>>>>>> 
>>>>>> On 01/02/2018 18:59, Mah

Re: [netmod] derived-from() vs derived-from-or-self() in acl model

[Mahesh Jethanandani]

> On Feb 26, 2018, at 1:31 PM, Per Hedeland <p...@tail-f.com> wrote:
> 
> On 2018-02-26 20:20, Mahesh Jethanandani wrote:
>>> On Feb 26, 2018, at 9:01 AM, Per Hedeland <p...@tail-f.com 
>>> <mailto:p...@tail-f.com>> wrote:
>>> 
>>> [Adding Cc todraft-ietf-netmod-acl-mo...@ietf.org 
>>> <mailto:draft-ietf-netmod-acl-mo...@ietf.org>]
>>> 
>>> On 2018-02-26 14:24, Ladislav Lhotka wrote:
>>>> Per Hedeland <p...@tail-f.com <mailto:p...@tail-f.com>> writes:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> A customer of ours using one of the draft versions of the
>>>>> ietf-access-control-list module reported that it was not possible to
>>>>> configure an ethernet ace with type acl:eth-acl-type, due to the
>>>>> derived-from() in
>>>>> 
>>>>>  container eth {
>>>>>when "derived-from(../../../../type, " +
>>>>> "'acl:eth-acl-type')";
>>>>>if-feature match-on-eth;
>>>>>uses pf:acl-eth-header-fields;
>>>>>description
>>>>>  "Rule set that matches ethernet headers.";
>>>>>  }
>>>>> 
>>>>> evaluating to "false". I pointed out that this is correct behavior of
>>>>> our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
>>>>> it would need to be derived-from-or-self() in order to evaluate to
>>>>> "true". I also ventured a guess (not having followed the development of
>>>>> the acl model in detail) that the intent was that vendors should define
>>>>> their own identities, that actually *were* derived from acl:eth-acl-type
>>>>> (and ditto for all the other *-acl-type identities, of course).
>>>>> 
>>>>> However I'm not at all sure that the guess is correct, and if so why
>>>>> this should be *enforced* by excluding the base identity. And having a
>>>>> look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
>>>>> seems to be doing exactly what our customer tried, alhough with
>>>>> ipv4-acl-type:
>>>>> 
>>>>> 
>>>>>  >>>> xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
>>>>>
>>>>>  sample-ipv4-acl
>>>>>  ipv4-acl-type
>>>>>  
>>>>>
>>>>>  rule1
>>>>>  
>>>>>
>>>>>  
>>>>>tcp
>>>>> 
>>>>> As far as I can see, this snippet is invalid for the model, since the
>>>>> 'ipv4' container has
>>>>> 
>>>>>  container ipv4 {
>>>>>when "derived-from(../../../../type, " +
>>>>> "'acl:ipv4-acl-type')";
>>>>> 
>>>>> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
>>>>> there shouldn't be any  element either, but that's another thing.)
>>>>> 
>>>>> So, is it the case that the derived-from()s should actually be
>>>>> derived-from-or-self()s, or is the example wrong?
>>>> 
>>>> This has to do with the irreflexivity property of identity derivation,
>>>> which is, in my view, an unnecessary complication. It would be simpler
>>>> but sufficient to define derivation as a reflexive relation, and have
>>>> only one "derived-from()" XPath function.
>>> 
>>> Be that as it may, it is obviously not what RFC 7950 says.
>> I would agree that that is not how I am reading RFC 7950. For now my choice 
>> is to change all the derived-from() to derived-from-or-self().
> 
> I think that is a useful change. FWIW, when I actually tried the example
> as the payload of an  towards our NETCONF server, I found
> some other problems, which I believe are still relevant with the pull
> request applied:
> 
> 1) (Aldready mentioned) the  element corresponding to the choice in
> the model should not be present (RFC 7950 section 7.9.5).

Removed . Although I have say the tree diagram confused me. It identifies 
l3 as a node with a +—rw next to it, while for ipv4 it says +—.

> 
> 2) "tcp" is 

Re: [netmod] ACL draft issues found during shepherd writeup

[Mahesh Jethanandani]

A pull request to address LC, shepherd, this and the other comments, including 
derived-from(), can be reviewed here:

https://github.com/netmod-wg/acl-model/pull/24 
<https://github.com/netmod-wg/acl-model/pull/24>

Thanks.

> On Feb 26, 2018, at 12:15 AM, Eliot Lear <l...@cisco.com> wrote:
> 
> 
> 
> On 26.02.18 06:55, Mahesh Jethanandani wrote:
>>> 
>>>> 
>>>> 
>>>>  PS: And this is not a shepherd directive, but I found the whole 
>>>>  "source-port-range-or-operator" syntax clumsy.  I'm surprised
>>>>  it didn't look something like:
>>>> 
>>>>  OLD
>>>>
>>>>   
>>>> 
>>>>   16384
>>>>   65535
>>>> 
>>>>   
>>>>
>>>> 
>>>>
>>>>  
>>>>
>>>>  eq
>>>>  21
>>>>
>>>>  
>>>>
>>>> 
>>>>  NEW
>>>> 
>>>>
>>>>  
>>>>16384
>>>>65535
>>>>  
>>>>
>>>> 
>>>>
>>>>  
>>>>eq
>>>>21
>>>>  
>>>>
>>>> 
>>>  
>>> Did you try making the change in the model to see if it work? It will 
>>> complain that  is already used within the container and that it 
>>> cannot be repeated (for destination-port).
>>> 
>>>  No, I did not, nor do I intend to get that deep into it.  But I 
>>> recall that Kristian made the same comment before, and was making pull 
>>> requests before, so maybe he can suggest something?
>> 
>> Kristian’s suggestion requires changing the module. It is not an editorial 
>> change. And that change will have an impact on the MUD draft, which has been 
>> sent for publication. 
>> 
> 
> As it happens, we found a bug in our augment statements, and so we will need 
> to rev one more time.  If the change can be made quickly, I can live with it.
> 
> Eliot

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] derived-from() vs derived-from-or-self() in acl model

[Mahesh Jethanandani]

> On Feb 26, 2018, at 9:01 AM, Per Hedeland <p...@tail-f.com> wrote:
> 
> [Adding Cc to draft-ietf-netmod-acl-mo...@ietf.org 
> <mailto:draft-ietf-netmod-acl-mo...@ietf.org>]
> 
> On 2018-02-26 14:24, Ladislav Lhotka wrote:
>> Per Hedeland <p...@tail-f.com> writes:
>> 
>>> Hi,
>>> 
>>> A customer of ours using one of the draft versions of the
>>> ietf-access-control-list module reported that it was not possible to
>>> configure an ethernet ace with type acl:eth-acl-type, due to the
>>> derived-from() in
>>> 
>>>   container eth {
>>> when "derived-from(../../../../type, " +
>>>  "'acl:eth-acl-type')";
>>> if-feature match-on-eth;
>>> uses pf:acl-eth-header-fields;
>>> description
>>>   "Rule set that matches ethernet headers.";
>>>   }
>>> 
>>> evaluating to "false". I pointed out that this is correct behavior of
>>> our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
>>> it would need to be derived-from-or-self() in order to evaluate to
>>> "true". I also ventured a guess (not having followed the development of
>>> the acl model in detail) that the intent was that vendors should define
>>> their own identities, that actually *were* derived from acl:eth-acl-type
>>> (and ditto for all the other *-acl-type identities, of course).
>>> 
>>> However I'm not at all sure that the guess is correct, and if so why
>>> this should be *enforced* by excluding the base identity. And having a
>>> look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
>>> seems to be doing exactly what our customer tried, alhough with
>>> ipv4-acl-type:
>>> 
>>> 
>>>   >> xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
>>> 
>>>   sample-ipv4-acl
>>>   ipv4-acl-type
>>>   
>>> 
>>>   rule1
>>>   
>>> 
>>>   
>>> tcp
>>> 
>>> As far as I can see, this snippet is invalid for the model, since the
>>> 'ipv4' container has
>>> 
>>>   container ipv4 {
>>> when "derived-from(../../../../type, " +
>>>  "'acl:ipv4-acl-type')";
>>> 
>>> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
>>> there shouldn't be any  element either, but that's another thing.)
>>> 
>>> So, is it the case that the derived-from()s should actually be
>>> derived-from-or-self()s, or is the example wrong?
>> 
>> This has to do with the irreflexivity property of identity derivation,
>> which is, in my view, an unnecessary complication. It would be simpler
>> but sufficient to define derivation as a reflexive relation, and have
>> only one "derived-from()" XPath function.
> 
> Be that as it may, it is obviously not what RFC 7950 says.

I would agree that that is not how I am reading RFC 7950. For now my choice is 
to change all the derived-from() to derived-from-or-self().

> 
>> Identities that are considered "abstract" should not be instantiated, and
>> then derived-from() and derived-from-or-self() give the same result.
> 
> So I guess your take is that the *-acl-type identities derived from
> acl:acl-base in the ietf-access-control-list module should be considered
> "abstract", and thus the example should not use ipv4-acl-type for the
> 'type' leaf, but instead some other identity derived from
> acl:ipv4-acl-type. Do the authors agree?
> 
> --Per
> 
>> Lada
>> 
>>> 
>>> --Per Hedeland
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netmod 
>>> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] ACL draft issues found during shepherd writeup

[Mahesh Jethanandani]

> On Feb 23, 2018, at 12:12 PM, Kent Watsen <kwat...@juniper.net> wrote:
> 
> Hi Mahesh,
>  
> Please search for  below (6 instances)
>  
> Thanks,
> Kent // shepherd
>  
>  
> On 2/17/18, 8:26 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com 
> <mailto:mjethanand...@gmail.com>> wrote:
>  
> Kent, 
>  
> Thanks for a detailed review. See inline.
> 
> 
>> On Feb 13, 2018, at 2:30 PM, Kent Watsen <kwat...@juniper.net 
>> <mailto:kwat...@juniper.net>> wrote:
>>  
>> [sorry, wrong WG, moving netconf to BCC!]
>> 
>> 
>> ACL Authors,
>> 
>> Below are some issues I found while looking at doing the Shepherd
>> write-up today.  Please take a look.
>> 
>> Also, with regards to the request for those having Last Call comments
>> to please verify that their comments were addressed, I only saw one
>> response from Kristian, but should we be expecting respeonses from
>> others too, perhaps Einar or Elliot?
>  
> Eliot can confirm if he feels his issues have been addressed.
> 
> 
>> 
>> 
>> 1 IDNITS
>> 
>>  - some issues found by idnits
>>  - using 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits_=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg=_5f-lxCoJW2TidcrjW_KbDkdPhfxLoL67kn1A2okgs0=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tools_idnits_=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg=_5f-lxCoJW2TidcrjW_KbDkdPhfxLoL67kn1A2okgs0=>
>>  - without selecting "verbose output"
>> 
>> 
>> 1.1
>> 
>>  ** There are 5 instances of too long lines in the document, the longest one
>> being 5 characters in excess of 72.
>  
> Fixed.
> 
> 
>> 
>> 
>>  This "**" is being flagged as an "error".  
>>  Idnits label, not mine.  Please fix.
>> 
>> 
>> 1.2
>> 
>>  == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
>> in the document.  If these are example addresses, they should be changed.
>> 
>>  This is just a warning, but given that there are seven occurrences, it
>>  might be a good idea to fix.  Please see Section 3, point #6 in this
>>  document for details: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_checklist=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg=AYo8ZHPY4SAHMqcy1qV9yr7BjoxGy_C9zcJ_ZbwXBT4=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id-2Dinfo_checklist=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg=AYo8ZHPY4SAHMqcy1qV9yr7BjoxGy_C9zcJ_ZbwXBT4=>.
>  
> Fixed.
> 
> 
>> 
>> 
>> 1.3
>> 
>>  ** The document seems to lack a both a reference to RFC 2119 and the
>> recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
>> keywords. 
>> 
>> RFC 2119 keyword, line 797: '...s-list. A device MAY restrict the 
>> leng...'
>> 
>> 
>>  There needs to be a section that looks like RFC 8174, paragraph 11:
>> 
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
>> and "OPTIONAL" in this document are to be interpreted as
>> described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>> appear in all capitals, as shown here.
>  
> Added.
> 
> 
>> 
>> 
>> 1.4.
>> 
>>  -- The document date (February 2, 2018) is 11 days in the past.  Is this
>> intentional?
>> 
>>  This is fine, ignore it.
>> 
>> 1.5
>> 
>>  ** Obsolete normative reference: RFC 2460
>> 
>>  This needs to be fixed.
>  
> Updated the reference to RFC 8200.
> 
> 
>> 
>> 1.6
>> 
>>  ** Downref: Normative reference to an Historic RFC: RFC 3540
>> 
>>  H, another HISTORIC document, but this time not due to an IESG
>>  action.  The question is how important this reference is, is this
>>  "ns" bit (ECN-nonce concealment protection) commonly used in the 
>>  

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[Mahesh Jethanandani]

> 
>
> 
> 
> 
> 
> 
>> ___
> 
>> netmod mailing list
> 
>> netmod@ietf.org
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
> 
>> 
> 
> 
> 
> 
> 
> 
> 
>___
> 
>netmod mailing list
> 
>netmod@ietf.org
> 
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vELsmeOQEHNm4fcyJJKG7EpwwzMBGc-MHvHhSPWRzro=jSGwP16XlM6ntMKUF3bkCAwRfRtRwATdly2BlUtx2RA=
>  
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vELsmeOQEHNm4fcyJJKG7EpwwzMBGc-MHvHhSPWRzro=jSGwP16XlM6ntMKUF3bkCAwRfRtRwATdly2BlUtx2RA=>
> 
> 
> 
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod 
> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanand...@gmail.com

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