[OPSAWG]Re: [IANA #1363824] Expert review for draft-ietf-opsawg-tsvwg-udp-ipfix (ipfix)

[mohamed . boucadair]

Re-,

> Is it possible to use unsigned256, say that topmost bits must be
> zero, and reduced size encoding MAY be used?

That was exactly what I initially proposed, but you seemed to question the RSE 
applicability 
(https://mailarchive.ietf.org/arch/msg/opsawg/VfPqkyXB07fe9VEneTXZ_2Z0-BY/)

Still, that is a hack.

IMO, a key use of the type is that it conveys the maximum allowed value by 
simply looking at the type of an IE:

(RFC7011)
   Note that the Information Element
   definitions [IANA-IPFIX] always define the maximum encoding size.

I can't speculate about future uses of the type, but looking at the past I see 
there are types that were defined (float32) since 2008 but never appear in the 
registry. U192 will at least have one IE associated with it.

If you insist to revert back to u255, please share OLD/NEW modifications you 
want to see.

Thank you.

Cheers,
Med 

> -Message d'origine-
> De : Aitken, Paul 
> Envoyé : mercredi 22 mai 2024 22:41
> À : drafts-expert-review-comm...@iana.org; BOUCADAIR Mohamed
> INNOV/NET 
> Cc : ie-doct...@ietf.org; opsawg@ietf.org
> Objet : Re: [IANA #1363824] Expert review for draft-ietf-opsawg-
> tsvwg-udp-ipfix (ipfix)
> 
> 
> Med,
> 
> I'm not happy with the unsigned192 type. It's uncommon, specific
> to the udpSafeOptions IE, and unlikely to be used again for
> anything else.
> 
> Is it possible to use unsigned256, say that topmost bits must be
> zero, and reduced size encoding MAY be used?
> 
> Thanks,
> P.
> 
> 
> On 22/05/24 20:11, David Dong via RT wrote:
> > Hi Paul,
> >
> > Following up on this document as well.
> >
> > Thank you for performing the reviews.
> >
> > Best regards,
> >
> > David Dong
> > IANA Services Sr. Specialist
> >
> > On Tue May 14 12:48:27 2024, mohamed.boucad...@orange.com
> wrote:
> >> Hi Paul,
> >>
> >> The new version with all received reviews and comments is
> available
> >> at:
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Furl
> >>
> defense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fd
> raft
> >> -ietf-opsawg-tsvwg-udp-
> __%3B!!OSsGDw!P_ycY1FkmBqO94I060aheNn8E63NSE_z
> >>
> 4Ch7kSKuTsFNGP209J80BBFfEJVL6LODmAf12QpGRtjzt0I5adRYNMo%24=0
> 5%7C
> >>
> 02%7Cmohamed.boucadair%40orange.com%7Cfd93ee91fabc4185328208dc7a9
> f800
> >>
> f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638520072665443067
> %7CU
> >>
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1h
> >>
> aWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=w48O80xT29sqg7OMzitY48Cgure
> 2GO2
> >> QNLAA%2BZl5pHg%3D=0 [datatracker[.]ietf[.]org] ipfix/
> >>
> >> Please see inline.
> >>
> >> Cheers,
> >> Med
> >>
> >> De : Aitken, Paul  Envoyé : lundi 13 mai
> 2024
> >> 21:53 À : BOUCADAIR Mohamed INNOV/NET
> ;
> >> drafts-expert-review-comm...@iana.org
> >> Cc : ie-doct...@ietf.org; opsawg  Objet : RE:
> >> [Ie-doctors] [IANA #1363824] Expert review for draft-ietf-
> >> opsawg-tsvwg-udp-ipfix (ipfix)
> >>
> >>
> >> Med,
> >>
> >> In the new version:
> >>
> >>
> >> 4.1. The first 64 most-significant bits MUST be set to 0.
> >>
> >> This seems to exclude reduced size encoding.
> >> [Med] These will be seen as leading zeros and will thus be
> reduced.
> >> However, I went with a unsigned192 rather than unsiggned256
> for this
> >> IE
> >>
> >>
> >> Also, "while Kind 255 corresponds to the most-significant bit
> of the
> >> IE." is nolonger accurate.
> >> [Med] Yes, changed to "191"
> >>
> >>
> >>
> >> 4.2 udpUnsfaeOptions
> >>
> >> Typo: udpUnsafeOptions
> >>
> >> [Med] Fixed.
> >>
> >>
> >> 4.1 and 4.2:
> >>
> >> A bit is set to 1
> >>
> >> should be "The bit is set to 1".
> >> [Med] OK
> >>
> >>
> >>
> >> 5.  Operational Considerations
> >>
> >> The note about reduced-size encoding will not be seen in
> IANA's
> >> registry.
> >> [Med] I moved that because this was a comment from Benoît to
> remove
> >> the reduced-size encoding from the description.
> >>
> >> The note seems contrary to the statement in 4.1 that I quoted
> above.
> >> [Med] That statement was removed.
> >>
> >>
> >> Figure 4:
> >>
> >> Repeating two points that I made previously:
> >>
> >> [Med] Fixed.
> >>
> >> The last 0x9858 (next to 0xC3D9) should be 0x9658. Else the
> figure
> >> does not correspond with the preceding text.
> >>
> >> 9658 and 9858 are unnecessarily similar values. I would urge
> you to
> >> choose a different example.
> >>
> >> 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. 

[OPSAWG]Re: [Ie-doctors] Re: [IANA #1363823] Expert review for draft-ietf-opsawg-ipfix-tcpo-v6eh (ipfix)

[mohamed . boucadair]

Hi Paul,

What prevails in that text is the wording in the guidance.

Made the changes to avoid confusion: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-tcpo-v6eh-15

Thanks.

Cheers,
Med

De : Aitken, Paul 
Envoyé : mercredi 22 mai 2024 22:25
À : BOUCADAIR Mohamed INNOV/NET ; 
drafts-expert-review-comm...@iana.org
Cc : ie-doct...@ietf.org; opsawg 
Objet : Re: [Ie-doctors] Re: [IANA #1363823] Expert review for 
draft-ietf-opsawg-ipfix-tcpo-v6eh (ipfix)

Med,

3.3.  ipv6ExtensionHeadersFull Information Element

  The value of ipv6ExtensionHeadersFull IE is encoded in fewer

  octets per the guidelines in Section 6.2 of [RFC7011].

If the value "is" encoded in fewer octets, then the defined size is simply too 
large. For clarity I'd say "may be encoded", even "MAY be", indicating that 
it's permissible to do so.





Same issue at 4.1:



  The value of tcpOptionsFull IE is encoded in fewer octets per the

  guidelines in Section 6.2 of [RFC7011].




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
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-15.txt

[internet-drafts]

Internet-Draft draft-ietf-opsawg-ipfix-tcpo-v6eh-15.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-15.txt
   Pages:   25
   Dates:   2024-05-22

Abstract:

   This document specifies new IP Flow Information Export (IPFIX)
   Information Elements (IEs) to solve 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-15.html

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

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


___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Fwd: New Liaison Statement, "LS on the new work item ITU-T Q.MUD_IoT “Framework for testing and monitoring IoT devices & networks using technical Requirements from Manufacturer Usage Descripti

[Mahesh Jethanandani]

FYI. 

Please work with ITU liaison, Scott Mansfield, if the WG thinks a response 
needs to be sent.

> Begin forwarded message:
> 
> From: Liaison Statement Management Tool 
> Subject: New Liaison Statement, "LS on the new work item ITU-T Q.MUD_IoT 
> “Framework for testing and monitoring IoT devices & networks using technical 
> Requirements from Manufacturer Usage Description (MUD)”"
> Date: May 22, 2024 at 10:17:52 AM PDT
> To: "The IETF Chair" 
> Cc: Scott Mansfield , Tatiana Kurakova 
> , The IESG , The IETF Chair 
> , itu-t-liai...@iab.org, liaison-coordinat...@iab.org
> 
> Title: LS on the new work item ITU-T Q.MUD_IoT “Framework for testing and 
> monitoring IoT devices & networks using technical Requirements from 
> Manufacturer Usage Description (MUD)”
> Submission Date: 2024-05-22
> URL of the IETF Web page: https://datatracker.ietf.org/liaison/1927/
> 
> From: Denis ANDREEV 
> To: The IETF Chair 
> Cc: The IETF Chair ,Scott Mansfield 
> ,itu-t-liai...@iab.org 
> ,The IESG 
> Response Contacts: Tatiana Kurakova 
> Technical Contacts: 
> Purpose: For information
> 
> Body: Abstract: This liaison statement informs ITU-T SG20, ITU-T SG13 and 
> IETF that SG11, particularly Q12/11, initiated a new work item: ITU-T 
> Q.MUD_IoT “Framework for testing and monitoring IoT devices & networks using 
> technical Requirements from Manufacturer Usage Description (MUD)”.
> 
> During the ITU-T SG11 meeting (Geneva, 01-10 May 2024), Q12/11 (Testing of 
> internet of things, its applications and identification systems) initiated a 
> new work item: ITU-T Q.MUD_IoT “Framework for testing and monitoring IoT 
> devices & networks using technical Requirements from Manufacturer Usage 
> Description (MUD)”.
> 
> ITU-T Q.MUD_IoT aims to propose a standardized framework for testing and 
> monitoring IoT devices & networks using technical requirements from the 
> Manufacturer Usage Description (MUD). This recommendation will also focus on 
> test scenarios and compliance criteria relevant to the behaviour and 
> communication patterns of IoT devices with mandatory requirements of MUD RFC 
> 8520. It does not cover test scenarios that verify implementation of other 
> network components such as MUD Controller/manager.
> 
> ITU-T Q12/11 would like to thank ITU-T SG20, ITU-T SG13 and IETF for their 
> attention and looks forward for further cooperation on this topic.
> 
> Attachment: 1
>  SG11-TD1017/GEN: Output – Initial baseline text of new work item ITU-T 
> Q.MUD_IoT “Framework for testing and monitoring IoT devices & networks using 
> technical Requirements from Manufacturer Usage Description (MUD) (Geneva, 
> 01-10 May 2024).
> Attachments:
> 
>LS196-Att_TD1017
>
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2024-05-22-itu-t-sg-11-ietf-ls-on-the-new-work-item-itu-t-qmud_iot-framework-for-testing-and-monitoring-iot-devices-networks-using-technica-attachment-1.pdf
> 
>LS196
>
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2024-05-22-itu-t-sg-11-ietf-ls-on-the-new-work-item-itu-t-qmud_iot-framework-for-testing-and-monitoring-iot-devices-networks-using-technica-attachment-2.docx
> 
> 


Mahesh Jethanandani
mjethanand...@gmail.com






___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: [IANA #1363824] Expert review for draft-ietf-opsawg-tsvwg-udp-ipfix (ipfix)

[Aitken, Paul]

Med,

I'm not happy with the unsigned192 type. It's uncommon, specific to the 
udpSafeOptions IE, and unlikely to be used again for anything else.

Is it possible to use unsigned256, say that topmost bits must be zero, 
and reduced size encoding MAY be used?

Thanks,
P.


On 22/05/24 20:11, David Dong via RT wrote:
> Hi Paul,
>
> Following up on this document as well.
>
> Thank you for performing the reviews.
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
> On Tue May 14 12:48:27 2024, mohamed.boucad...@orange.com wrote:
>> Hi Paul,
>>
>> The new version with all received reviews and comments is available
>> at: 
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-__;!!OSsGDw!P_ycY1FkmBqO94I060aheNn8E63NSE_z4Ch7kSKuTsFNGP209J80BBFfEJVL6LODmAf12QpGRtjzt0I5adRYNMo$
>>  [datatracker[.]ietf[.]org]
>> ipfix/
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>> De : Aitken, Paul 
>> Envoyé : lundi 13 mai 2024 21:53
>> À : BOUCADAIR Mohamed INNOV/NET ;
>> drafts-expert-review-comm...@iana.org
>> Cc : ie-doct...@ietf.org; opsawg 
>> Objet : RE: [Ie-doctors] [IANA #1363824] Expert review for draft-ietf-
>> opsawg-tsvwg-udp-ipfix (ipfix)
>>
>>
>> Med,
>>
>> In the new version:
>>
>>
>> 4.1. The first 64 most-significant bits MUST be set to 0.
>>
>> This seems to exclude reduced size encoding.
>> [Med] These will be seen as leading zeros and will thus be reduced.
>> However, I went with a unsigned192 rather than unsiggned256 for this
>> IE
>>
>>
>> Also, "while Kind 255 corresponds to the most-significant bit of the
>> IE." is nolonger accurate.
>> [Med] Yes, changed to “191”
>>
>>
>>
>> 4.2 udpUnsfaeOptions
>>
>> Typo: udpUnsafeOptions
>>
>> [Med] Fixed.
>>
>>
>> 4.1 and 4.2:
>>
>> A bit is set to 1
>>
>> should be "The bit is set to 1".
>> [Med] OK
>>
>>
>>
>> 5.  Operational Considerations
>>
>> The note about reduced-size encoding will not be seen in IANA's
>> registry.
>> [Med] I moved that because this was a comment from Benoît to remove
>> the reduced-size encoding from the description.
>>
>> The note seems contrary to the statement in 4.1 that I quoted above.
>> [Med] That statement was removed.
>>
>>
>> Figure 4:
>>
>> Repeating two points that I made previously:
>>
>> [Med] Fixed.
>>
>> The last 0x9858 (next to 0xC3D9) should be 0x9658. Else the figure
>> does not correspond with the preceding text.
>>
>> 9658 and 9858 are unnecessarily similar values. I would urge you to
>> choose a different example.
>>
>> 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
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: [Ie-doctors] Re: [IANA #1363823] Expert review for draft-ietf-opsawg-ipfix-tcpo-v6eh (ipfix)

[Aitken, Paul]

Med,


3.3.  ipv6ExtensionHeadersFull Information Element

  The value of ipv6ExtensionHeadersFull IE is encoded in fewer
  octets per the guidelines in Section 6.2 of [RFC7011].


If the value "is" encoded in fewer octets, then the defined size is simply too 
large. For clarity I'd say "may be encoded", even "MAY be", indicating that 
it's permissible to do so.



Same issue at 4.1:

  The value of tcpOptionsFull IE is encoded in fewer octets per the
  guidelines in Section 6.2 of [RFC7011].




P.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG][IANA #1363824] Expert review for draft-ietf-opsawg-tsvwg-udp-ipfix (ipfix)

[David Dong via RT]

Hi Paul,

Following up on this document as well.

Thank you for performing the reviews.

Best regards,

David Dong
IANA Services Sr. Specialist

On Tue May 14 12:48:27 2024, mohamed.boucad...@orange.com wrote:
> Hi Paul,
> 
> The new version with all received reviews and comments is available
> at: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-
> ipfix/
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> De : Aitken, Paul 
> Envoyé : lundi 13 mai 2024 21:53
> À : BOUCADAIR Mohamed INNOV/NET ;
> drafts-expert-review-comm...@iana.org
> Cc : ie-doct...@ietf.org; opsawg 
> Objet : RE: [Ie-doctors] [IANA #1363824] Expert review for draft-ietf-
> opsawg-tsvwg-udp-ipfix (ipfix)
> 
> 
> Med,
> 
> In the new version:
> 
> 
> 4.1. The first 64 most-significant bits MUST be set to 0.
> 
> This seems to exclude reduced size encoding.
> [Med] These will be seen as leading zeros and will thus be reduced.
> However, I went with a unsigned192 rather than unsiggned256 for this
> IE
> 
> 
> Also, "while Kind 255 corresponds to the most-significant bit of the
> IE." is nolonger accurate.
> [Med] Yes, changed to “191”
> 
> 
> 
> 4.2 udpUnsfaeOptions
> 
> Typo: udpUnsafeOptions
> 
> [Med] Fixed.
> 
> 
> 4.1 and 4.2:
> 
> A bit is set to 1
> 
> should be "The bit is set to 1".
> [Med] OK
> 
> 
> 
> 5.  Operational Considerations
> 
> The note about reduced-size encoding will not be seen in IANA's
> registry.
> [Med] I moved that because this was a comment from Benoît to remove
> the reduced-size encoding from the description.
> 
> The note seems contrary to the statement in 4.1 that I quoted above.
> [Med] That statement was removed.
> 
> 
> Figure 4:
> 
> Repeating two points that I made previously:
> 
> [Med] Fixed.
> 
> The last 0x9858 (next to 0xC3D9) should be 0x9658. Else the figure
> does not correspond with the preceding text.
> 
> 9658 and 9858 are unnecessarily similar values. I would urge you to
> choose a different example.
> 
> 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
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG][IANA #1363823] Expert review for draft-ietf-opsawg-ipfix-tcpo-v6eh (ipfix)

[David Dong via RT]

Hi Paul,

Following up on this document as well.

Thank you for performing the reviews.

Best regards,

David Dong
IANA Services Sr. Specialist

On Tue May 14 05:21:33 2024, mohamed.boucad...@orange.com wrote:
> Hi Paul,
> 
> Thanks for double checking.
> 
> I don’t think there is a conflict between 3.3/3.4-3.6 because these
> are covering distinct aspects of the information export.
> 
> Fixed the nit.
> 
> Cheers,
> Med
> 
> De : Aitken, Paul 
> Envoyé : lundi 13 mai 2024 22:13
> À : BOUCADAIR Mohamed INNOV/NET ;
> drafts-expert-review-comm...@iana.org
> Cc : ie-doct...@ietf.org; opsawg 
> Objet : Re: [Ie-doctors] Re: [IANA #1363823] Expert review for draft-
> ietf-opsawg-ipfix-tcpo-v6eh (ipfix)
> 
> 
> Med,
> 
> 
> 3.3.
> 
> Extension headers observed in a Flow with varying extension header
> chain MAY be aggregated in one single ipv6ExtensionHeadersFull
> Information Element or be exported in separate
> ipv6ExtensionHeadersFull IEs, one for each extension header chain.
> 
> Seems to contradict these paragraphs:
> 
> 3.4.
> 
> Each header chain in Flow with varying extension header chain MUST
> be exported in a separate IE.
> 
> 3.6
> 
> Each header chain length of a Flow with varying extension header
> 
> chain MUST be exported in a separate
> 
> ipv6ExtensionHeadersChainLength IE.
> 
> 
> 
> 6.1. remove ",and" :
> 
> Figure 2 provides another example of reported values in an
> 
> ipv6ExtensionHeadersFull IE for an IPv6 Flow in which the Destination
> 
> Options (0), IPv6 Hop-by-Hop Options (1), and Routing (5), and
> 
> headers are observed.
> 
> 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
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]I-D Action: draft-ietf-opsawg-tacacs-tls13-10.txt

[internet-drafts]

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

   Title:   Terminal Access Controller Access-Control System Plus (TACACS+) 
over TLS 1.3
   Authors: Thorsten Dahm
John Heasley
Douglas C. Medway Gash
Andrej Ota
   Name:draft-ietf-opsawg-tacacs-tls13-10.txt
   Pages:   15
   Dates:   2024-05-22

Abstract:

   The Terminal Access Controller Access-Control System Plus (TACACS+)
   Protocol provides device administration for routers, network access
   servers and other networked computing devices via one or more
   centralized servers.  This document adds Transport Layer Security
   (TLS 1.3) support to TACACS+ and obsoletes former inferior security
   mechanisms.

   This document updates RFC8907.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-10.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-10

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


___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: [Ie-doctors] Re: [IANA #1363822] Expert review for draft-ietf-opsawg-ipfix-fixes (ipfix)

[Paul Aitken]

Thanks Med, that looks great.

David, I approve the -10.

P.


On 22/05/24 07:42, mohamed.boucad...@orange.com wrote:


Hi Paul,

-10 fixes all these, including the ToC level.

Thank you.

Cheers,

Med

*De :* Aitken, Paul 
*Envoyé :* mardi 21 mai 2024 22:58
*À :* BOUCADAIR Mohamed INNOV/NET ; 
drafts-expert-review-comm...@iana.org

*Cc :* ie-doct...@ietf.org; opsawg 
*Objet :* Re: [Ie-doctors] [IANA #1363822] Expert review for 
draft-ietf-opsawg-ipfix-fixes (ipfix)



Med,



* In the TOC, all the OLD / NEW section names are distracting. It
would be much more readable if the TOC was limited to just two levels:

    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4

    2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5

    3.  Why An RFC is Needed for These Updates? . . . . . . . . . . .   6

    4.  Update the Description  . . . . . . . . . . . . . . . . . . .   6

  4.1.  sourceTransportPort . . . . . . . . . . . . . . . . . . .   6

  4.2.  destinationTransportPort  . . . . . . . . . . . . . . . .   7

      4.3.  forwardingStatus  . . . . . . . . . . . . . . . . . . . .   8


Is this not possible?



  


* 6.11.2 NEW


Please append [RFC5102 [iana.org]

]
here.

For the methods parameters, Information Elements are defined
in the information model document *[RFC5102]*.

*/[Med] OK as that was the intent at the time. However, given that
5102 is obsoleted, should we simply point to the registry itself
instead of 5102?/*


Yes please, that seems good.


6.22.2. NEW

Typo: remove "at" in the registry name:

    SeemibCaptureTimeSemanticsat  registry at

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.

___
ie-doctors mailing list --ie-doct...@ietf.org
To unsubscribe send an email toie-doctors-le...@ietf.org
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: Opsdir last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-10

[mohamed . boucadair]

Hi Jouni, 

Good catch. This is now fixed in -11. 

Thank you for the review.

Cheers,
Med

> -Message d'origine-
> De : Jouni Korhonen via Datatracker 
> Envoyé : mercredi 22 mai 2024 05:57
> À : ops-...@ietf.org
> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Opsdir last call review of draft-ietf-opsawg-tsvwg-udp-
> ipfix-10
> 
> 
> Reviewer: Jouni Korhonen
> Review result: Has Nits
> 
> I am the assigned OPS-DIR reviewer for this draft. Apologies for
> a late review.
> 
> Summary: The document is ready with nits.
> 
> I found the document solid and ready. One minor comment below:
> 
> In section 4.1:
>   options.  For example, if only option Kinds <= 32 are
> observed,
>   then the value of the udpSafeOptions IE can be encoded as
>   unsigned32, or if only option Kinds <= 63 are observed,
> then the
> 
> Shouldn't it say:
>   options.  For example, if only option Kinds <= 31 are
> observed,
> 
> 


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
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]I-D Action: draft-ietf-opsawg-tsvwg-udp-ipfix-11.txt

[internet-drafts]

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

   Title:   Export of UDP Options Information in IP Flow Information Export 
(IPFIX)
   Authors: Mohamed Boucadair
Tirumaleswar Reddy.K
   Name:draft-ietf-opsawg-tsvwg-udp-ipfix-11.txt
   Pages:   13
   Dates:   2024-05-21

Abstract:

   This document specifies new IP Flow Information Export (IPFIX)
   Information Elements for UDP options.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Operations and
   Management Area Working Group Working Group mailing list
   (opsawg@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/opsawg/.

   Source for this draft and an issue tracker can be found at
   https://github.com/boucadair/udp-ipfix.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-tsvwg-udp-ipfix-11.html

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

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


___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: [Ie-doctors] [IANA #1363822] Expert review for draft-ietf-opsawg-ipfix-fixes (ipfix)

[mohamed . boucadair]

Hi Paul,

-10 fixes all these, including the ToC level.

Thank you.

Cheers,
Med

De : Aitken, Paul 
Envoyé : mardi 21 mai 2024 22:58
À : BOUCADAIR Mohamed INNOV/NET ; 
drafts-expert-review-comm...@iana.org
Cc : ie-doct...@ietf.org; opsawg 
Objet : Re: [Ie-doctors] [IANA #1363822] Expert review for 
draft-ietf-opsawg-ipfix-fixes (ipfix)


Med,



* In the TOC, all the OLD / NEW section names are distracting. It would be much 
more readable if the TOC was limited to just two levels:

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4

   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5

   3.  Why An RFC is Needed for These Updates? . . . . . . . . . . .   6

   4.  Update the Description  . . . . . . . . . . . . . . . . . . .   6

 4.1.  sourceTransportPort . . . . . . . . . . . . . . . . . . .   6

 4.2.  destinationTransportPort  . . . . . . . . . . . . . . . .   7

 4.3.  forwardingStatus  . . . . . . . . . . . . . . . . . . . .   8

Is this not possible?





* 6.11.2 NEW

Please append [RFC5102 
[iana.org]]
 here.
For the methods parameters, Information Elements are defined in the information 
model document [RFC5102].

[Med] OK as that was the intent at the time. However, given that 5102 is 
obsoleted, should we simply point to the registry itself instead of 5102?

Yes please, that seems good.


6.22.2. NEW

Typo: remove "at" in the registry name:

   See mibCaptureTimeSemanticsat registry at




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
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]I-D Action: draft-ietf-opsawg-ipfix-fixes-10.txt

[internet-drafts]

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

   Title:   Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry
   Authors: Mohamed Boucadair
Benoit Claise
   Name:draft-ietf-opsawg-ipfix-fixes-10.txt
   Pages:   37
   Dates:   2024-05-21

Abstract:

   This document provides simple fixes to the IANA IP Flow Information
   Export (IPFIX) registry.  Specifically, this document provides
   updates to fix shortcomings in the description of some Information
   Elements (IE), updates to ensure a consistent structure when citing
   an existing IANA registry, and updates to fix broken pointers,
   orphaned section references, etc.  The updates are also meant to
   bring some consistency among the entries of the registry.

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

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

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

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


___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org