Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-04

[Martin Björklund]

mohamed.boucad...@orange.com wrote:
> Hi Martin,
> 
> Thanks for the review.
> 
> FWIW, a new version that fixes the nit you reported and other minor pending 
> we had is available online: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ac-lxsm-lxnm-glue-05

That was quick!  However, the spelling error is still there, and I
think you introduced a new one ;-)


was provisionned using the ACaaS module.";


Thansk to Martin Björklund for the yangdoctors review.
^^



/martin






> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Martin Björklund via Datatracker 
> > Envoyé : mercredi 24 janvier 2024 16:18
> > À : yang-doct...@ietf.org
> > Cc : draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org; opsawg@ietf.org
> > Objet : Yangdoctors early review of draft-ietf-opsawg-ac-lxsm-lxnm-
> > glue-04
> > 
> > Reviewer: Martin Björklund
> > Review result: Ready with Nits
> > 
> > This is a very short, and from a YANG-perspective simple, module. It
> > looks good, and I also found one nit: s/provisionned/provisioned/g
> > 
> > /martin
> > 
> 
> 
> 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.

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

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-04

[mohamed . boucadair]

Hi Martin,

Thanks for the review.

FWIW, a new version that fixes the nit you reported and other minor pending we 
had is available online: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ac-lxsm-lxnm-glue-05

Cheers,
Med

> -Message d'origine-
> De : Martin Björklund via Datatracker 
> Envoyé : mercredi 24 janvier 2024 16:18
> À : yang-doct...@ietf.org
> Cc : draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org; opsawg@ietf.org
> Objet : Yangdoctors early review of draft-ietf-opsawg-ac-lxsm-lxnm-
> glue-04
> 
> Reviewer: Martin Björklund
> Review result: Ready with Nits
> 
> This is a very short, and from a YANG-perspective simple, module. It
> looks good, and I also found one nit: s/provisionned/provisioned/g
> 
> /martin
> 


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

[OPSAWG] I-D Action: draft-ietf-opsawg-ac-lxsm-lxnm-glue-05.txt

[internet-drafts]

Internet-Draft draft-ietf-opsawg-ac-lxsm-lxnm-glue-05.txt is now available. It
is a work item of the Operations and Management Area Working Group (OPSAWG) WG
of the IETF.

   Title:   A YANG Data Model for Augmenting VPN Service and Network Models 
with Attachment Circuits
   Authors: Mohamed Boucadair
Richard Roberts
Samier Barguil Giraldo
Oscar Gonzalez de Dios
   Name:draft-ietf-opsawg-ac-lxsm-lxnm-glue-05.txt
   Pages:   28
   Dates:   2024-01-24

Abstract:

   The document specifies a module that updates existing service and
   network Virtual Private Network (VPN) modules with the required
   information to bind specific services to ACs that are created using
   the Attachment Circuit (AC) service and network models.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-ac-lxsm-lxnm-glue-05.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ac-lxsm-lxnm-glue-05

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

[OPSAWG] Yangdoctors early review of draft-ietf-opsawg-ntw-attachment-circuit-04

[Martin Björklund via Datatracker]

Reviewer: Martin Björklund
Review result: Ready with Issues

Here is my YANG doctor's review of draft-ietf-opsawg-ntw-attachment-circuit-04.

o  There are several typedefs defined on the form:

  typedef attachment-circuit-reference {
type leafref {
  path "/nw:networks/nw:network/nw:node/ac-ntw:ac/ac-ntw:name";
}

  Note that this path spans three lists (network, node, ac).  Unless
  it is guaranteed that the `ac-ntw:ame` value is unique within all
  networks and all nodes, this typedef won't work (or rather, it may
  refer to more than one ac).


o typedef ac-profile-reference {
type leafref {
  path "/nw:networks/nw:network/ac-profile/name";
}

  The nodes should have prefixes:

  path "/nw:networks/nw:network/ac-ntw:ac-profile/ac-ntw:name";


o   leaf site-of-origin {
  when "../address-family = 'vpn-common:ipv4' "
 + "or 'vpn-common:dual-stack'" {

leaf ipv6-site-of-origin {
  when "../address-family = 'vpn-common:ipv6' "
 + "or 'vpn-common:dual-stack'" {


   Use 'derived-from-or-self' instead of comparison.


o  Some lists have plural-names: routing-profiles, ipv4-lan-prefixes,
   ipv6-lan-prefixes.  Usually lists should have singular names.


o typedef encryption-profile-reference {
...
description
  "Defines a type to an encryption profile for referencing
   purposes.";
  }

  Perhaps "Defines a reference to an encryption profile"?

  (Same for 4 more typedefs)



/martin


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

[OPSAWG] Yangdoctors early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-04

[Martin Björklund via Datatracker]

Reviewer: Martin Björklund
Review result: Ready with Nits

This is a very short, and from a YANG-perspective simple, module. It looks
good, and I also found one nit: s/provisionned/provisioned/g

/martin


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

Re: [OPSAWG] 🔔 WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Evans, John]

Hi Benoit,

Thanks for your feedback.

> I mean: what is the value of an information model without a respective
> data model, or a mapping to data model(s)?

Whilst it's true that having a data model is essential for implementing an 
information model effectively, our focus is on standardising a framework for 
packet loss reporting.  Once the information model is agreed, we can proceed to 
apply that to the corresponding data models.  Separating the process into two 
phases allows us to ensure that the information model itself is well defined 
for network operations use cases and can be used across multiple data models.

Cheers

John


On 24/01/2024, 05:07, "OPSAWG on behalf of Benoit Claise" 
mailto:opsawg-boun...@ietf.org> on behalf of 
benoit.claise=40huawei@dmarc.ietf.org > 
wrote:


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Dear all,


See in-line.


On 1/17/2024 12:51 PM, Henk Birkholz wrote:
> Dear OPSAWG members,
>
> this email starts a call for Working Group Adoption of
>
>> https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html 
>> 
>
> ending on Wednesday, January 31st.
>
> As a reminder, this I-D describes an information model in support of
> automated network mitigation on what and how to report about
> unintentional packet discards/losses that can have an impact on
> service level objectives. Implementation of the informational model,
> which could manifest, e.g., via NETCONF/YANG, SNMP or IPFIX, is
> out-of-scope.
I read the previous version, and even provided feedback to John.
This is interesting work and I like the way the information it's
structured.
However, I am asking myself: what is the value of information model
these days?
I mean: what is the value of an information model without a respective
data model, or a mapping to data model(s)?


Regards, Benoit
>
> The chairs acknowledge feedback to and interest for the topic during
> the IETF118 meeting and on the list after afterwards. We would like to
> gather feedback from the WG if there is interest to further contribute
> and review.
>
> Please reply with your support and especially any substantive comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org 
> https://www.ietf.org/mailman/listinfo/opsawg 
> 


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







Amazon Data Services UK Limited. Registered in England and Wales with 
registration number 09959151 with its registered office at 1 Principal Place, 
Worship Street, London, EC2A 2FA, United Kingdom.


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

Re: [OPSAWG] 🔔 WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Benoit Claise]

Dear all,

See in-line.

On 1/17/2024 12:51 PM, Henk Birkholz wrote:

Dear OPSAWG members,

this email starts a call for Working Group Adoption of


https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html


ending on Wednesday, January 31st.

As a reminder, this I-D describes an information model in support of 
automated network mitigation on what and how to report about 
unintentional packet discards/losses that can have an impact on 
service level objectives. Implementation of the informational model, 
which could manifest, e.g., via NETCONF/YANG, SNMP or IPFIX, is 
out-of-scope.

I read the previous version, and even provided feedback to John.
This is interesting work and I like the way the information it's 
structured.
However, I am asking myself: what is the value of information model 
these days?
I mean: what is the value of an information model without a respective 
data model, or a mapping to data model(s)?


Regards, Benoit


The chairs acknowledge feedback to and interest for the topic during 
the IETF118 meeting and on the list after afterwards. We would like to 
gather feedback from the WG if there is interest to further contribute 
and review.


Please reply with your support and especially any substantive comments 
you may have.



For the OPSAWG co-chairs,

Henk

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


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

Re: [OPSAWG] 🔔 WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Tianran Zhou]

Hi Authors,

I read this draft and I think this work is valuable. 
There are several comments for your consideration.
1.  We have YANG as the modeling language for configuration DM. For this draft, 
do you have any formal language for the IM? While I think the tree diagram is 
also clear, I am afraid the expression is not very strict.
2. The title indicates the content is about discard. And in fact section 4.1 
only described the discard class. However, the IM you proposed includes 
"traffic"  as a large part. So, I am thinking if you would consider to remove 
the "traffic" part, or your document is actually a more generic traffic IM.
3. In section 5, all your Signal-Cause-Mitigation mapping examples are actually 
"discard". Is there any use case for "good traffic"? I.e., maybe there is no 
need for the "good traffic" report, hence no need to include the "traffic" in 
your draft for your scenario.
4. In section 5, the Signal-Cause-Mitigation table is confusing. It's not clear 
what's the signal, cause, mitigation respectively. So it's better to indicate 
this information explicitly in the table.

Best,
Tianran

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Henk Birkholz
Sent: Wednesday, January 17, 2024 8:52 PM
To: OPSAWG 
Subject: [OPSAWG] 🔔 WG Adoption Call for draft-opsawg-evans-discardmodel-02

Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.htm
> l

ending on Wednesday, January 31st.

As a reminder, this I-D describes an information model in support of automated 
network mitigation on what and how to report about unintentional packet 
discards/losses that can have an impact on service level objectives. 
Implementation of the informational model, which could manifest, e.g., via 
NETCONF/YANG, SNMP or IPFIX, is out-of-scope.

The chairs acknowledge feedback to and interest for the topic during the
IETF118 meeting and on the list after afterwards. We would like to gather 
feedback from the WG if there is interest to further contribute and review.

Please reply with your support and especially any substantive comments you may 
have.


For the OPSAWG co-chairs,

Henk

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

Re: [OPSAWG] [**EXTERNAL**] RE: [IPFIX] WG LC: IPFIX documents

[mohamed . boucadair]

Hi Paul,

Thanks for the follow-up. Much appreciated.

Please see inline.

Cheers,
Med

De : Aitken, Paul 
Envoyé : mardi 23 janvier 2024 18:25
À : BOUCADAIR Mohamed INNOV/NET ; Joe Clarke 
(jclarke) ; opsawg@ietf.org
Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org
Objet : Re: [**EXTERNAL**] RE: [IPFIX] WG LC: IPFIX documents

Med,


Why does the document identify issues without proposing solutions to them all? 
How and when will those other issues be fixed?
[Med] The new IEs in this I-D fix all the issues.

Then please don't write "some of".
[Med] We do already say “this section specifies a set of new IEs to address 
**all the ipv6ExtensionHeaders IE limitations **”.





 MSB LSB

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 |  EH Type#1|   Count   |...|  EH Type#n  |   Count   |

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Abstract Data Type:  unsigned64

This is neither a simple IE, nor an unsigned64. It's a structured data type, ie 
a variable-length array of { type, count } tuples.
[Med] Do we need to define a new type for this?

See subTemplateList in RFC 6313.

   Examples include a structured data type composed of multiple pairs of
   ("MPLS label stack entry position", "MPLS label stack value")

which is similar to what's proposed here: multiple pairs of { type, count }.

[Med] Please find the candidate changes at Diff: 
draft-ietf-opsawg-ipfix-tcpo-v6eh.txt - 
draft-ietf-opsawg-ipfix-tcpo-v6eh.txt.

Again, the "octetArray" type is somewhat misleading as it's really a 32tetArray.
[Med] I’m not sure this is problematic given that the definition of octetArray 
indicates explicitly the following:
   The octetArray data type has no encoding rules; it represents a raw
   array of zero or more octets, with the interpretation of the octets
   defined in the Information Element definition.

32-bit values are being encoded, not octets.
[Med] This is now discussed in a separate thread. Let’s try to converge there. 
Thanks.

7.  Security Considerations

The ipv6ExtensionHeadersChainLength could be used to determine hardware 
capabilities and limitations, and possibly even to identify the hardware 
through which the traffic is flowing.
[Med] Not sure how this can be used to identify the hardware.

The reported values will be hardware specific, so the information could be used 
for hardware fingerprinting. Insufficient on its own, but potentially useful in 
combination with other information.

The point is that no other IEs encode specific information about hardware 
capabilities.

[Med] Added this note:

“ipv6ExtensionHeadersChainLength and ipv6ExtensionHeadersLimit IEs can be 
exploited by an unauthorized observer as a means to deduce the processing 
capabilities of nodes. {{Section 8 of !RFC7012}} discusses the required 
measures to guarantee the integrity and confidentiality of the exported 
information.”


P.

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