Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-acceptable-urls-09.txt

[Michael Richardson]

internet-dra...@ietf.org wrote:
> A diff from the previous version is available at:
> 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-mud-acceptable-urls-09

The only change is the addition of an empty IANA Considerations section as
requested by the shepherd write up.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-mud-acceptable-urls-09.txt

[internet-drafts]

Internet-Draft draft-ietf-opsawg-mud-acceptable-urls-09.txt is now available.
It is a work item of the Operations and Management Area Working Group (OPSAWG)
WG of the IETF.

   Title:   Authorized update to MUD URLs
   Authors: Michael Richardson
Wei Pan
Eliot Lear
   Name:draft-ietf-opsawg-mud-acceptable-urls-09.txt
   Pages:   14
   Dates:   2024-01-17

Abstract:

   This document provides a way for an RFC8520 Manufacturer Usage
   Description (MUD) definitions to declare what are acceptable
   replacement MUD URLs for a device.

   RFCEDITOR-please-remove: this document is being worked on at:
   https://github.com/mcr/iot-mud-acceptable-urls

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-acceptable-urls-09.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-mud-acceptable-urls-09

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

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Carlos Pignataro]

Many thanks, Med, for the review and useful suggestions!

I seem to prefer path-coupled to path-congruent as well.

I also like the packet-embedded or user-packet-embedded alternatives, as
they do seem more clear than in-packet.

WG - Any other thoughts on this?

Adrian, what do you think? (including as a native speaker)

Thanks a lot!

Carlos.

On Wed, Jan 17, 2024 at 12:32 PM  wrote:

> Hi Carlos, Adrian, all,
>
>
>
> Thank you for editing this document. This is really useful.
>
>
>
> Alternate terms to consider for the path-congruent terms are
> path-coupled/path-decoupled OAM (inspired from RFC4080).
>
>
>
> When editing RFC 9451, I wish I had terms for:
>
>- “OAM packet that exclusively includes OAM data”
>- “OAM packet that includes user data”
>
>
>
> I don’t think “in-packet OAM” conveys unambiguously the intent. I would
> suggest explicit terms such as: “User Data Embedded OAM” or “OAM-embedded
> User Data”.
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG  *De la part de* Carlos Pignataro
> *Envoyé :* vendredi 5 janvier 2024 21:39
> *À :* Ops Area WG ; Adrian Farrel 
> *Objet :* [OPSAWG] New I-D -> Guidelines for Charactering "OAM"
>
>
>
> Hi, Ops Area WG,
>
>
>
> Every now and again, there are discussions on how to best characterize or
> qualify a particular kind of "OAM", as well as misunderstandings due to
> having different definitions and contexts for a given term. A case in point
> is "in-band" or "out-of-band" OAM, as recently surfaced at
> https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/.
>
>
>
> To alleviate this issue, Adrian and I wrote a short I-D to provide
> forward-looking guidance on "foobar OAM".
>
>
>
> We would appreciate feedback and input on this position, which aims at
> updating the guidelines for the "OAM" acronym, with unambiguous guidelines
> for their modifiers.
>
>
>
> Guidelines for Charactering "OAM":
>
>
> https://datatracker.ietf.org/doc/draft-pignataro-opsawg-oam-whaaat-question-mark/
>
>
>
> Look forward to input and comments to make this more clear and effective!
>
>
>
> Adrian & Carlos.
>
>
>
>
>
> 
> 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] New I-D -> Guidelines for Charactering "OAM"

[mohamed . boucadair]

Hi Carlos, Adrian, all,

Thank you for editing this document. This is really useful.

Alternate terms to consider for the path-congruent terms are 
path-coupled/path-decoupled OAM (inspired from RFC4080).

When editing RFC 9451, I wish I had terms for:

  *   "OAM packet that exclusively includes OAM data"
  *   "OAM packet that includes user data"

I don't think "in-packet OAM" conveys unambiguously the intent. I would suggest 
explicit terms such as: "User Data Embedded OAM" or "OAM-embedded User Data".

Thank you.

Cheers,
Med

De : OPSAWG  De la part de Carlos Pignataro
Envoyé : vendredi 5 janvier 2024 21:39
À : Ops Area WG ; Adrian Farrel 
Objet : [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

Hi, Ops Area WG,

Every now and again, there are discussions on how to best characterize or 
qualify a particular kind of "OAM", as well as misunderstandings due to having 
different definitions and contexts for a given term. A case in point is 
"in-band" or "out-of-band" OAM, as recently surfaced at 
https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/.

To alleviate this issue, Adrian and I wrote a short I-D to provide 
forward-looking guidance on "foobar OAM".

We would appreciate feedback and input on this position, which aims at updating 
the guidelines for the "OAM" acronym, with unambiguous guidelines for their 
modifiers.

Guidelines for Charactering "OAM":
https://datatracker.ietf.org/doc/draft-pignataro-opsawg-oam-whaaat-question-mark/

Look forward to input and comments to make this more clear and effective!

Adrian & Carlos.



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-ipfix-tcpo-v6eh-08.txt

[internet-drafts]

Internet-Draft draft-ietf-opsawg-ipfix-tcpo-v6eh-08.txt is now available. It
is a work item of the Operations and Management Area Working Group (OPSAWG) WG
of the IETF.

   Title:   Extended TCP Options and IPv6 Extension Headers IPFIX Information 
Elements
   Authors: Mohamed Boucadair
Benoit Claise
   Name:draft-ietf-opsawg-ipfix-tcpo-v6eh-08.txt
   Pages:   16
   Dates:   2024-01-17

Abstract:

   This document specifies new IP Flow Information Export (IPFIX)
   Information Elements (IEs) to solve some issues with existing
   ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability
   to export any observed IPv6 extension headers or TCP options.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-tcpo-v6eh-08.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-tcpo-v6eh-08

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

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[mohamed . boucadair]

Re-,

What about adding the following under "Operational Considerations":

NEW:
Implementations of tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs are 
assumed to be provided with a list of valid Experiment IDs {{IANA-TCP-EXIDs}}. 
How that list is maintained is implementation-specific. Absent that list, an 
implementation can't autonomously determine whether an ExID is present and, if 
so, whether it is 2- or 4-byte length.

Cheers,
Med

> -Message d'origine-
> De : Wesley Eddy 
> Envoyé : mercredi 17 janvier 2024 14:25
> À : BOUCADAIR Mohamed INNOV/NET ;
> tsv-...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org;
> opsawg@ietf.org
> Objet : Re: Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-
> v6eh-05
> 
> On 1/17/2024 3:34 AM, mohamed.boucad...@orange.com wrote:
> > [Med] This can be part of regular code updates. Please note
> that this
> > is not unusual in ipfix (see for example ipv4Options, natevent,
> etc.
> > in
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.iana.org%2Fassignments%2Fipfix%2Fipfix.xhtml=05%7C02%7C
> mohamed.boucadair%40orange.com%7C69fc748e4be24a2aa56808dc175fb703
> %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638410947053802590%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=eZcICzC8rw%2BLDau
> B82e4BxG2PkB5X3LRQO%2BDCUmGQyU%3D=0 which depend on an
> IANA registry).
> 
> Ok; do you think the document should explain this in a sentence
> or two for implementers?
> 
> If they are not all familiar with details of how ExIDs are used,
> then it seems like a stretch to assume they'll all understand
> that products need to be designed to periodically update ExID
> definitions.


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]  IPR Call for draft-opsawg-evans-discardmodel-02

[Henk Birkholz]

Dear authors and contributors,

as a part of the adoption process, the chairs would also like to issue a 
first IPR call on the content of adoption candidates (there will also be 
a second IPR call after successful WGLC).


Please respond on-list as to whether or not you are aware of any IPR 
that pertains to draft-opsawg-evans-discardmodel-02.


If you are aware of IPR, please also indicate whether or not this has 
been disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179).



For the OPAWG co-chairs,

Henk

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

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

[mohamed . boucadair]

Hi all, 

I support adopting this document.

The authors kindly addressed many of my comments in -02. 

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de Henk Birkholz
> Envoyé : mercredi 17 janvier 2024 13:52
> À : OPSAWG 
> Objet : [OPSAWG]  WG Adoption Call for draft-opsawg-evans-
> discardmodel-02
> 
> Dear OPSAWG members,
> 
> this email starts a call for Working Group Adoption of
> 
> >...
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg=05%7C02%7Cmohame
> d.boucadair%40orange.com%7Ceb16c148d3b842238cb108dc175b30d7%7C90c
> 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638410927624831726%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=XRWG1pDgYi9R9FHSrY4tnzn
> V3rhYlq%2BAvR%2BjN3QlZG0%3D=0

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] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy]

On 1/17/2024 3:34 AM, mohamed.boucad...@orange.com wrote:
[Med] This can be part of regular code updates. Please note that this 
is not unusual in ipfix (see for example ipv4Options, natevent, etc. 
in https://www.iana.org/assignments/ipfix/ipfix.xhtml which depend on 
an IANA registry).


Ok; do you think the document should explain this in a sentence or two 
for implementers?


If they are not all familiar with details of how ExIDs are used, then it 
seems like a stretch to assume they'll all understand that products need 
to be designed to periodically update ExID definitions.


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

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

[Diego R. Lopez]

Hi,

As I think I already had the opportunity to express in past meetings, this 
proposal is of high interest for service providers. I support adoption.

Be goode,

--
“Esta vez no fallaremos, Doctor Infierno”

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Mobile: +34 682 051 091
-

On 17/1/24, 12:52,  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.

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



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

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

[Thomas.Graf]

Dear OPSAWG,



I read the document and think it is very valuable for network operators. I like 
that it is defined as information module so later we can see how this would be 
applicable in IPFIX and YANG.



Best wishes

Thomas



-Original Message-
From: OPSAWG  On Behalf Of Henk Birkholz
Sent: Wednesday, January 17, 2024 1:52 PM
To: OPSAWG 
Subject: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02





Be aware: This is an external email.







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


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Henk Birkholz]

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.


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] AD review of draft-ietf-opsawg-9092-update-08

[Rob Wilton (rwilton)]

Hi Authors, OPSAWG,


Please see my AD review comments for draft-ietf-opsawg-9092-update-08.  My 
focus was on the diff between the latest draft and RFC 9092.  I only have some 
relatively minor comments.

Minor level comments:



(1) p 4, sec 3.  inetnum: Class



   Any particular inetnum: object SHOULD have, at most, one geofeed

   reference, whether a remarks: or a proper geofeed: attribute when it

   is implemented.  If there is more than one, the geofeed: attribute

   SHOULD be used.



I don't find this text as clear as it could be.  Given the recommendation is to 
have a single geofeed reference, then I think that it would be helpful to 
provide guidance as to what format that geofeed reference should take.  I.e., I 
presume that the geofeed reference SHOULD also use the geofeed: attribute 
format if the RIR supports it or the remarks attribute otherwise?





(2) p 9, sec 6.  Operational Considerations



   The geofeed files MUST be published via and fetched using HTTPS

   [RFC9110].



Also note you have a similiar RFC 2119 statement in section 4, and I wonder 
whether it would be clearer to only have the formal requirement listed in one 
place and referenced from the other place?





(3) p 9, sec 6.  Operational Considerations



   The geofeed files MUST be published via and fetched using HTTPS

   [RFC9110].



It is interesting that the geofeed files MUST be fetched using HTTPS, but 
earlier the RIR's FTP SHOULD be used to gather the geofeed references.  
Presumably if the RIR data was available via HTTPS that could also be used?





(4) p 11, sec 9.  Security Considerations



   The consumer of geofeed data SHOULD fetch and process the data

   themselves.  Importing datasets produced and/or processed by a third-

   party places ill-advised trust in the third-party.



This feels like quite a strong statement to make, and I wonder whether it won't 
be better to just point out the risks of using a third-party and then allow the 
reader to decide whether to accept that risk?







Nit level comments:



(5) p 7, sec 5.  Authenticating Geofeed Data (Optional)



   Identifying the private key associated with the certificate and

   getting the department that controls the private key (which might be

   stored in a Hardware Security Module (HSM)) to generate the CMS

   signature is left as an exercise for the implementor.  On the other

   hand, verifying the signature has no similar complexity; the

   certificate, which is validated in the public RPKI, contains the

   needed public key.  The RPKI trust anchors for the RIRs are expected

   to already be available to the party performing signature validation.

   Validation of the CMS signature over the geofeed file involves:



involves: => "involves the following steps:", or you need to change back Obtain 
... => Obtaining ..., etc.

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

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-teas-attachment-circuit-03

[mohamed . boucadair]

Hi Ebben,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Ebben Aries 
> Envoyé : lundi 15 janvier 2024 16:49
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : yang-doct...@ietf.org; draft-ietf-opsawg-teas-attachment-
> circuit@ietf.org; opsawg@ietf.org
> Objet : Re: Yangdoctors early review of draft-ietf-opsawg-teas-
> attachment-circuit-03
> 
> Thx Med - one comment inline...
> 
> On 2024-01-15 06:59:58, mohamed.boucad...@orange.com wrote:
> > [External Email. Be cautious of content]
> >
> >
...
> >
> > > - For `status/admin-status/last-change`, this leaf is `r/w`
> and
> > > while I
> > >   realize this is reuse from `ietf-vpn-common`, it seems that
> this
> > > is
> > >   incorrect and should be reflected as pure `r/o` state.
> >
> > [Med] Actually, no. Unlike the operational status, the client
> can control that for administrative status as well. Think about
> scheduled operations for example.
> 
> I'm conflicted why this would reside in modeling for the use-case
> you describe as this would entail a pattern that would need to be
> considered across _all_ modeling.

[Med] This is fair.

  I'm not sure I've seen this
> pattern arise before.
> 
> RFC7758 is one such example of how scheduled operations would be
> handled at the protocol messaging layer and not scattered among
> the data-content.

[Med] Please note that we are focusing mainly on service and network models, 
for which NETCONF may be the transport protocol, but I hear your point. 

Given that for the AC models, we do define the following for a client to 
control when a service can be activate/deactivated:

  grouping op-instructions
+-- requested-start?   yang:date-and-time
+-- requested-stop?yang:date-and-time
+--ro actual-start?  yang:date-and-time
+--ro actual-stop?   yang:date-and-time

And that for advanced scheduling, the WG is working on a generic model 
(draft-ma-opsawg-schedule-yang) that can be used in a future ac augments if 
needed, I tweaked the draft so that the admin last-change is ro instead of rw. 
The diff to track the changes can be seen at:

* Diff ac-common: 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-common-ac.diff
* diff ac-svc: 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-attachment-circuit.diff

Better? 

Thank you for you patience.


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] [Int-dir] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

[mohamed . boucadair]

Hi Joe,

The very short introduction to SAFE/UNSAFE is there to help reader digest the 
difference between EXP and UEXP introduced right after and understand the 
rationale for having two IPFIX IEs.

Of course, the authoritative reference for implementers is the TSVWG base spec; 
the exact section citations are provided.

I still prefer maintaining that text for now.

Thank you.

Cheers,
Med

De : to...@strayalpha.com 
Envoyé : mardi 16 janvier 2024 18:30
À : BOUCADAIR Mohamed INNOV/NET 
Cc : int-...@ietf.org; draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; 
opsawg@ietf.org
Objet : Re: [Int-dir] Intdir early review of 
draft-ietf-opsawg-tsvwg-udp-ipfix-03

I’d actually like to suggest this doc avoid repeating information in other 
docs, notably the UDP options spec.

In particular:
- there is no need to replicate Fig 1
- there is no need to replicate the definitions of SAFE or UNSAFE

All these things can be “as defined in X”. That avoids any issues if there are 
subtle changes to these, notably the definitions.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com


On Jan 16, 2024, at 12:28 AM, 
mohamed.boucad...@orange.com wrote:

Hi Joe,

Thanks for the follow-up.

Please see inline.

Cheers,
Med

De : to...@strayalpha.com 
mailto:to...@strayalpha.com>>
Envoyé : lundi 15 janvier 2024 17:17
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : int-...@ietf.org; 
draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org;
 opsawg@ietf.org
Objet : Re: Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

Please see below.

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com



On Jan 15, 2024, at 12:26 AM, 
mohamed.boucad...@orange.com wrote:

Hi Joe,

Thanks for the review.

Please see inline.

Cheers,
Med



-Message d'origine-
De : Joseph Touch via Datatracker mailto:nore...@ietf.org>>
Envoyé : samedi 13 janvier 2024 05:03
À : int-...@ietf.org
Cc : 
draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org;
opsawg@ietf.org
Objet : Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-
03

Reviewer: Joseph Touch
Review result: Ready with Issues

This review is performed as part of the INTAREA cross-area
review.

There do not appear to be any INTAREA issues in this document.

NOTE: as author of the UDP options on which this document is
based, I have some other concerns noted below, which are the
"issues" indicated in the review result (ready with issues).

There are some misconceptions about UDP options that should be
corrected in this document:

Regarding SAFE options:
-   “Such options can be silently ignored by receivers
without affecting
the meaning of the UDP user data” -   Should be “Such options
can be
silently ignored by legacy receivers because they do not alter
the UDP user data”

Regarding UNSAFE options:
-   “Such options are not safe to ignore”
-   Should be “Such options are not safe tor legacy receivers
to ignore
because they alter the UDP user data”

[Med] Fixed.

It would be useful to use a consistent phrase to describe the "UDP user data" 
(e.g., as per your Fig 1), i.e., rather than also “UDP data payload”.
[Med] Updated the text to use consistent wording for both safe/unsafe text.



The document should be more clear that UDP options occur per-
packet within a flow and can be introduced at any time in the
flow (unlike TCP).

[Med] Added a new statement to echo this. The export process covers any option 
that is observed in a flow.




Sec 4.1 needs to indicate use of a field with 256 possible
values; it currently is defined for only 32 or 64 values.



[Med] 32/64 are provided as examples to illustrate the use of reduced encoding. 
The full 256 range is covered in the spec. Thanks.

“Unsigned” without numeric qualifiers is not an IPFIX data type, per RFC7011 
Sec 6.1.1.

Sec 6.2 indicates the specific encoding types where reduced encoding applies, 
and also uses unsigned only with numeric qualifiers.

[Med] You are right. Updated the text to use a new abstract data type defined 
in another ongoing opsawg-ipfix spec.

Joe





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 

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[mohamed . boucadair]

Hi Wes,

Please see inline.

Cheers,
Med

De : Wesley Eddy 
Envoyé : mardi 16 janvier 2024 21:21
À : BOUCADAIR Mohamed INNOV/NET ; tsv-...@ietf.org
Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; opsawg@ietf.org
Objet : Re: Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

On 1/16/2024 11:10 AM, 
mohamed.boucad...@orange.com wrote:
Are you expecting the implementation to have an exhaustive list of all of the 
ExIDs in use to understand the difference between 2 and 4 byte usage?
[Med] Yes because otherwise an implem can’t unambiguously identify and extract 
ExIDs. We do provide a pointer to the registered ExIDs:

==
Additional Information:  See assigned ExIDs at [IANA-TCP-EXIDs].
==

Please let me know if you still think a clarification is needed to the draft. 
Thanks.

New ExIDs are able to be added to the IANA registry at any time, just via 
requesting them.  Is an IPFIX implementation expected to periodically fetch the 
registry and reload its known values?

[Med] This can be part of regular code updates. Please note that this is not 
unusual in ipfix (see for example ipv4Options, natevent, etc. in 
https://www.iana.org/assignments/ipfix/ipfix.xhtml which depend on an IANA 
registry).

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