from:"mohamed . boucadair"

Hi Paul,

Thank you for the careful review and good suggestions. Went with almost all of 
them.

Please see inline for more context.

Cheers,
Med

De : ipv6  De la part de Aitken, Paul
Envoyé : lundi 22 janvier 2024 22:50
À : Joe Clarke (jclarke) ; opsawg@ietf.org
Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org
Objet : Re: [IPv6] [IPFIX] WG LC: IPFIX documents

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes


Abstract

The updates are also meant to bringing some
consistency among the entries of the registry.

Typo, "meant to bring in".
[Med] OK.

1.  Introduction

As the OPSAWG is currently considering

This will soon become outdated. Consider, "When OPSAWG was considering ..."

[Med] OK

not adequately specified any longer

"nolonger adequately specified"

[Med] OK

This document intends to update the IANA registry
   and bringing some consistency among the entries of the registry.

Typo, "bring".

[Med] OK

As discussed with IANA

Say when and/or where.

[Med] updated the text to indicate that this was during the publication process 
of RFC9487.


   *  Miscellaneous updates that fix broken pointers, orphan section
  references, etc.  (Section 7).

Typo, "orphaned".


4.1.2.  Updates to the ipv6ExtensionHeaders Description

Consider making "OLD" into 4.1.2.1 and "NEW" into 4.1.2.2.

Likewise for all the other OLD / NEW sections - its easier to read now, and 
will be easier to xref in future.

[Med] Good suggestion. Fixed.


Additional Information:

See RFC Errata 1738.

Please restore the xref.
[Med] OK.

  The following drawing indicates
  the position of each bit in the encoding of the Information
  Element.

No, not any more - so this should be removed.

[Med] It is useful as it indicates the bit position that is then referred to in 
the new IANA registry. Updated the figure to make that clearer.

  This IE is used only when the observed extension headers are in
  the 0-31 range.

Consider deprecating this IE in favour of ipv6ExtensionHeadersFull.
[Med]  Seems reasonable, but would like to hear more from the WG.

4.2.1.  Issues

   Only options having a kind =< 63 can be included in a tcpOptions IE.

Conventionally, "<= 63".
[Med] OK


4.2.2.  Update the Description of the tcpOptions IE

This information element is used only when the observed
 kinds are within the 0-63 range.  If not, the tcpOptionsFull IE

Consider deprecating this IE in favour of tcpOptionsFull.
[Med] Seems reasonable, but would like to hear more from the WG.

4.3.  forwardingStatus

In particular, the registered Abstract
   Data Type is unsigned8, while it must be unsigned32.

Why must it be?
[Med] As per the definition in RFC7270.

   Future versions may be defined to associate
   meanings with the remaining bits.

This is an old Cisco NetFlow compatible IE. It seems unlikely that there would 
be any future versions. If there were, a new IE should be defined.
Therefore it seems better to leave it as an unsigned8 and correct RFC 7270.

[Med] I prefer to maintain the current text in the draft. unsigned8 will be 
used anyway because of the reduced-encoding.

See the Forwarding Status sub-registries at
https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status

An xref would be shorter and neater, eg "See the Forwarding Status 
sub-registries at [FORWARDING-STATUS]".
[Med] Agree but we are using the same format as it appears in the IANA registry.


- Additional Information: See "NetFlow Version 9 Flow-Record Format"
(CCO-NF9FMT).

"CCO-NF9FMT" makes no sense here. It's an xref in the IANA registry, so make it 
an xref in this document.

[Med] Done.


6.  Consistent Citation of IANA Registries

   This document requests IANA to update [IANA-IPFIX] for each of the IE
   entries listed in the following subsections.

This does not explain the changes or why they are required. It's necessary for 
the reader to individually compare each "old" and "new" section.

[Med] We don't repeat that here because we do already have the following in the 
introduction:


   *  Updates that are meant to ensure a consistent structure when

  calling an existing IANA registry (Section 6).

Rather than writing an explanation for each change as was done in each 4.x.1 
sub-section, a single note here could indicate that in each case the updates 
move the URLs into the Additional Information section.


6.1.  mplsTopLabelType

This text has been omitted from "NEW" :

See the list of MPLS label types assigned by IANA at
[https://www.iana.org/assignments/mpls-label-values].

[Med] This one was removed on purpose as the assigned values are provided in 
the IANA IPFIX registry and there is no explicit mapping between the two 
registries.


6.2.  classificationEngineId

  -  Additional Information:  See https://www.iana.org/assignments

Re: [OPSAWG] draft-ietf-opsawg-ipfix-tcpo-v6eh-08 shepherd review

Hi Thomas, 

Thank you  much for preparing the writeup. 

I'm not sure I received the comments mentioned in point 14 of the writeup, 
though. I suspect this is because of the issues I'm having with the IETF 
aliases. Please forward me offline these comments. Thanks and apologies for the 
inconvenience.

Cheers,
Med

> -Message d'origine-
> De : thomas.g...@swisscom.com 
> Envoyé : dimanche 21 janvier 2024 09:45
> À : draft-ietf-opsawg-ipfix-tcpo-v6eh.auth...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh.cha...@ietf.org;
> opsawg@ietf.org
> Objet : draft-ietf-opsawg-ipfix-tcpo-v6eh-08 shepherd review
> 
> Dear Med and Benoit,
> 
> Thanks a lot. The document is very well written and straight forward.
> As shared previously during the working group, I believe this document
> is very valuable to network operators since it addresses current
> issues in the observation of IPv6 headers and TCP options.
> 
> I have reviewed the document and wrote the initial shepherd review
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-tcpo-
> v6eh%2Fshepherdwriteup%2F&data=05%7C02%7Cmohamed.boucadair%40orange.co
> m%7C70d60422fea24fc37be708dc1a5d4799%7C90c7a20af34b40bfbc48b9253b6f5d2
> 0%7C0%7C0%7C638414235128846317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> ata=eFdqPjtvSpB7Z8Q4iG6ORBrX10TFrwraz3d1yJRtsbs%3D&reserved=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] [IPFIX] WG LC: IPFIX documents

Hi Paul,

Thank you very much for the detailed review.

There are some points that are common to the udp spec. Will discuss those in 
separate threads.

Please see inline.

Cheers,
Med

De : tsvwg  De la part de Aitken, Paul
Envoyé : vendredi 19 janvier 2024 10:52
À : Joe Clarke (jclarke) ; opsawg@ietf.org
Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org
Objet : Re: [tsvwg] [IPFIX] WG LC: IPFIX documents

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh

Essentially the middle of this document is missing: a summary of issues is 
given and new IEs are proposed as a solution. But the issues are not developed 
or explained.


1.1.  Issues with ipv6ExtensionHeaders Information Element

   *  Specify a means to export the order and the number of occurences
  of a given extension header.

Typo, "occurrences"
[Med] Fixed.

The specification of ipv6ExtensionHeaders IPFIX IE does not:

Consider including the IE number for clarity, eg "The specification of 
ipv6ExtensionHeaders IPFIX IE (#64) does not:"

Same for 1.2 (tcpOptions, #209).
[Med] Sure. Went for (64) and (209).


   *  Describe how any observed TCP option in a Flow can be exported
  using IPFIX.  Only TCP options having a kind =< 63 can be exported
  in a tcpOptions IPFIX IE.

Conventionally "<=" is used.
[Med] OK
3.  Information Elements for IPv6 Extension Headers

   The definition of the ipv6ExtensionHeaders IE is updated in
   Section 4.1 of [I-D.ietf-opsawg-ipfix-fixes] to address some of the
   issues listed in Section 1.1.
For clarity say, "Section 1.1 above", else it seems to refer to 1.1 of 
ietf-opsawg-ipfix-fixes.
[Med] Added "of this document".

   The definition of the ipv6ExtensionHeaders IE is updated in
   Section 4.1 of [I-D.ietf-opsawg-ipfix-fixes] to address some of the
   issues listed in Section 1.1.  Because some of these limitations
   cannot be addressed by simple updates to ipv6ExtensionHeaders, this
   section specifies a set of new IEs to address all the
   ipv6ExtensionHeaders IE limitations.

Please expand on this and explain "some of": which issues are addressed and 
which are not?
[Med] This is already covered by this pointer: "Refer also to {{Section 4.1.1 
of ?I-D.ietf-opsawg-ipfix-fixes}} for more details.". We do already have two 
paragraphs there with these details. No need to be redundant here.
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.

3.1 - 3.4

These definitions should be in the IANA section.

Section 3 should explain the problems and how they are solved, rather than 
jumping straight to the IEs as a fait-accompli.
[Med] The issues and rationale are already provided in previous sections, hence 
the current structure.
3.1.  ipv6ExtensionHeadersFull Information Element
Please include some discussion and justification for creating this new element 
rather than updating the existing ipv6ExtensionHeaders IE (#64). If the 
existing IE cannot be updated then explain backwards compatibility between the 
proposed and existing IEs and deprecate the existing IE.
[Med] This is explained in the other spec and have a clear statement that the 
new IE MUST be used when the range is exceeded, etc.

The information is encoded in a set of bit fields.
It sounds like a singular bit field rather than a set of bit fields.
[Med] Hmm, this is a well used terminology in IPFIX IE description. Please 
check the IANA registry.
  In doing so,
  few octets will be needed to encode common IPv6 extension headers
  when observed in a Flow.
This justification should be part of the discussion I mentioned above, and not 
part of the definition.


The "No Next Header" (59) value is used

Add an xref for the 59.
[Med] Added a pointer to {{Section 4.7 of !RFC8200}}.

  This Information Element SHOULD NOT be exported if
  ipv6ExtensionHeaderCount Information Element is also present.

Explain why not. This explanation should be in the text rather than in the 
definition.
This should possibly be in section 5.1 where the 3rd paragraph discusses 
similar limitations.
[Med] Moved to 5.1. The reason is that the content of the IEs is redundant. 
Will see how to convey that in the text.

   Abstract Data Type:  unsigned256

No, it's a bitfield. unsigned256 represents an integer, which this is not.
[Med] Will reply to this one in a separate message as this is also discussed in 
the udp spec.
3.2.  ipv6ExtensionHeaderCount Information Element

   Description:  As per Section 4.1 of [RFC8200], IPv6 nodes must accept
  and attempt to process extension headers in occurring any number
Typo, "in".
[Med] Fixed.

 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

[OPSAWG] errata eid7775 RE: [EXTERNAL] RE: [IPFIX] WG LC: IPFIX documents

Re-,

Please see inline.

Cheers,
Med

De : Aitken, Paul 
Envoyé : mardi 23 janvier 2024 11:26
À : 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,


  The following drawing indicates
  the position of each bit in the encoding of the Information
  Element.

No, not any more - so this should be removed.


[Med] It is useful as it indicates the bit position that is then referred to in 
the new IANA registry. Updated the figure to make that clearer.

The previous drawing indicated the positions of specific bits. The new drawing 
does not indicate the position of any of the bits:

0 1 2 3 4 5 6 7

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

|IPv6 extension header bits |  ...

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



[Med] Please see the new drawing at 
https://boucadair.github.io/simple-ipfix-fixes/draft-ietf-opsawg-ipfix-fixes.html


  This IE is used only when the observed extension headers are in
  the 0-31 range.

Consider deprecating this IE in favour of ipv6ExtensionHeadersFull.
[Med]  Seems reasonable, but would like to hear more from the WG.

It would be worth proposing the deprecations in a separate email thread, 
because I can't imagine anyone else is following in sufficient detail.

[Med] Fair enough.

4.3.  forwardingStatus

In particular, the registered Abstract
   Data Type is unsigned8, while it must be unsigned32.

Why must it be?
[Med] As per the definition in RFC7270.

I've opened an errata for that: https://www.rfc-editor.org/errata/eid7775
[Med] I don' think an erratum applies here because the intent of 7270 is 
clearly unsigned32:

   Description:
  This Information Element describes the forwarding status of the
  flow and any attached reasons.  The reduced-size encoding rules as
  per [RFC7011] apply.

  The basic encoding is 8 bits.  The future extensions
  could add one or three bytes.  The layout of the basic
  encoding is as follows:

6.10.  natType

Please take the opportunity to add the missing description, eg "This element 
identifies the type of NAT applied to packets of the flow."


[Med] Thanks. Went for: « This Information Element identifies the NAT type 
applied to packets of the Flow.".

Thanks; that looks good.


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

[OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

> It is consistent but wrong, as the numeric value of these fields is 
> meaningless. Bitfields with flags semantics don't have a meaningful 
> "unsigned" value.

You raised this comment for both TCP/UDP specs.

As I mentioned in the previous message, all existing IEs of type flags are 
using an unsigned type. Also, please note that rfc7012#section-3.2.5 says the 
followings:

   "flags" is an integral value that represents a set of bit fields.
   Logical operations are appropriate on such values, but other
   mathematical operations are not.  Flags MUST always be of an unsigned
   data type.

And rfc7012#section-3:

   Abstract data types unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and signed64 are integral data types.
   As described in Section 3.2, their data type semantics can be further

   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier', or 'flags'.
 ^^

I quite don't understand why we need to define Bitfields rather than leveraging 
on the approach followed so far in IPFIX.

Cheers,
Med

De : Aitken, Paul 
Envoyé : lundi 22 janvier 2024 11:49
À : BOUCADAIR Mohamed INNOV/NET ; Aitken, Paul 
; Joe Clarke (jclarke) 
; opsawg@ietf.org
Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org
Objet : Re: Re: [IPFIX] WG LC: IPFIX documents

Med,


   The IE specified in Section 4.1 uses the new abstract data type
   defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

The unsigned256 type? It makes more sense to introduce a bitfield type.
[Med] I think the use of unsigned256 is consistent with the current use in IP 
Flow Information Export (IPFIX) Entities (iana.org) 
[iana.org]
 (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs 
having data semantic of flags.

It is consistent but wrong, as the numeric value of these fields is 
meaningless. Bitfields with flags semantics don't have a meaningful "unsigned" 
value.

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] octetArray/hextetArray/32tetArray RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

(restricted the distribution lists to OPSAWG and IPFIX)

The octetArray type is especially confusing as these are really hextetArrays.


[Med] Not sure we need a new data type here as octeArray is defined as follows:
   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.

The draft proposes the encoding not of octets, but of 16-bit values. Therefore 
it's not an "array of zero or more octets" but rather, an "array of zero or 
more hextets".

[Med] I was assuming that ___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] deprecating ipv6ExtensionHeaders and tcpOptions IEs RE: [IPFIX] WG LC: IPFIX documents

Re-,

Paul suggested to tag these two IEs as deprecated in favor of the new full IEs.

I do personally think this is OK (especially given what Andrew reported at: 
https://mailarchive.ietf.org/arch/msg/opsawg/QNm9p8V2vKuhUX5rxBCqcxD-WAY/), but 
would like to hear if there objections to proceed with that path.

Cheers,
Med

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

...

De : ipv6 mailto:ipv6-boun...@ietf.org>> De la part de 
Aitken, Paul
Envoyé : lundi 22 janvier 2024 22:50
À : Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org
Cc : t...@ietf.org; 
ts...@ietf.org; 6...@ietf.org; 
ip...@ietf.org
Objet : Re: [IPv6] [IPFIX] WG LC: IPFIX documents

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes


Consider deprecating this IE in favour of ipv6ExtensionHeadersFull.
[Med]  Seems reasonable, but would like to hear more from the WG.


Consider deprecating this IE in favour of tcpOptionsFull.
[Med] Seems reasonable, but would like to hear more from the WG.



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] [EXTERNAL] RE: [IPFIX] WG LC: IPFIX documents

2024-01-24 Thread 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

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

2024-01-24 Thread 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

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

2024-01-25 Thread mohamed . boucadair

Hi Martin,

Thanks for the review. 

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Martin Björklund via Datatracker 
> Envoyé : mercredi 24 janvier 2024 16:20
> À : yang-doct...@ietf.org
> Cc : draft-ietf-opsawg-ntw-attachment-circuit@ietf.org;
> opsawg@ietf.org
> Objet : Yangdoctors early review of draft-ietf-opsawg-ntw-attachment-
> circuit-04
> 
> 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).
> 

[Med] Good catch. We don't have that constraint on the "ac-ntw:name". Please 
see the candidate changes to fix this at: 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-ntw-attachment-circuit.txt&url_2=https://boucadair.github.io/attachment-circuit-model/boucadair-patch-5/draft-ietf-opsawg-ntw-attachment-circuit.txt.
 The use of groupings for references is consistent with the approach in RFC 
8345.

> 
> 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";
> 

[Med] Fixed.

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

[Med] Agree. Fixed.

> 
> o  Some lists have plural-names: routing-profiles, ipv4-lan-prefixes,
>ipv6-lan-prefixes.  Usually lists should have singular names.
> 
 
[Med] Fixed.

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

[Med] Works for me. Thanks.

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

2024-01-25 Thread mohamed . boucadair

Hi Martin, 

Thank you for the follow-up.

Fixed the nits in the yang file. Also updated the module to make use of the new 
groupings for referencing purposes instead of the broken typedefs in the 
ac-ntw: 

https://author-tools.ietf.org/api/iddiff?iddiff?doc_1=draft-ietf-opsawg-ac-lxsm-lxnm-glue&url_2=https://boucadair.github.io/attachment-circuit-model/boucadair-patch-5/draft-ietf-opsawg-ac-lxsm-lxnm-glue.txt
 

Cheers,
Med

> -Message d'origine-
> De : Martin Björklund 
> Envoyé : mercredi 24 janvier 2024 16:52
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : yang-doct...@ietf.org; draft-ietf-opsawg-ac-lxsm-lxnm-
> glue@ietf.org; opsawg@ietf.org
> Objet : Re: Yangdoctors early review of draft-ietf-opsawg-ac-lxsm-
> lxnm-glue-04
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-ac-lxsm-lxnm-
> glu
> > e-
> 05&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C46a62fe529bd44020
> >
> 91308dc1cf473e7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638417083
> >
> 964251050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> >
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C41000%7C%7C%7C&sdata=ZWGtBagO6Z2BiYEH
> > xG8yqYJwwzj72LPLDoUVEKRHM2U%3D&reserved=0
> 
> 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.

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] Submission of new version of TACACS+ TLS Spec (V4)

2024-01-25 Thread mohamed . boucadair

Hi Authors, all,

Many thanks for your effort on this document.

I managed finally to read the new version. I'm afraid that some of the comments
in
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-tacacs-tls13-03-rev%20Med.pdf
were not addressed or at least I fail to see how they are.

For example, I still don't think that we can separate the discussion of the
port number from how the IP address of the server is configured. I still also
think that cipher suite discuss can be offloaded to RFC9325 (which btw should
be cited as normative; also, please note that RFC7525 is now obsoleted by
RFC9325).

Cheers,
Med

De : OPSAWG De la part de Douglas Gash (dcmgash)
Envoyé : vendredi 22 décembre 2023 17:54
À : opsawg@ietf.org
Cc : John Heasly ; Andrej Ota
Objet : [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)

Dear OPSAWG,

Many thank for all the comments on the Secure TACACS+ (TLS) draft v3.

We have submitted a revised doc which intention to address the concerns and
comments. It is rather later than originally planned, our apologies for the
delay. We will look forward to addressing the corresponding issues form this
revision in a timelier manner.

Some brief notes regarding the broader topics raised in v3, all items of
course, are open for re-aligning as the group sees fit.

* Regarding the allocation of a specific port, a key motivation concerns
the pervasive use of default ports in current configurations. Ensuring the
client implementations work correctly with default ports now TLS is introduced,
to minimise burden for operators whilst avoiding wrinkles with downgrade
attacks does require said new default port to be allocated, and we will
explicitly mention this in a new section in the new doc. We hope this should
help account for our request for an allocated port.
* RFC9325 does look a timely reference, and we have tried to delegate what
we can from the new TACACS+ doc to it.
* Tracking the discussion on the deprecation of obfuscation option inside
TLS, our current reading is that:

* All TLS traffic must NOT use obfuscation.
* Setting the non-obfuscation option (TACACS has a flag for unencrypted)
is mandatory for all TLS TACACS+ traffic.
* The aim is to avoid any ambiguity and to remove MD5 operations from
this level of the protocol.

* We hope we have addressed the raised issues nits and ambiguities.

Best regards, the Authors.

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] draft-ietf-opsawg-ipfix-fixes-05 shepherd review

2024-02-04 Thread mohamed . boucadair

Hi Thomas, all,

 

Thanks for preparing the writeup. Looks good to me.

 

I hope to receive more feedback on whether we mark these two IEs as
deprecated.

 

For forwardingStatus, I reiterate that the type should be unsigned32
as per the RFC.

 

Cheers,

Med

 

De : thomas.g...@swisscom.com  
Envoyé : samedi 3 février 2024 12:09
À : draft-ietf-opsawg-ipfix-fixes.auth...@ietf.org
Cc : draft-ietf-opsawg-ipfix-fixes.cha...@ietf.org; opsawg@ietf.org
Objet : draft-ietf-opsawg-ipfix-fixes-05 shepherd review

 

Dear Med and Benoit,

 

Thanks a lot. The document is straight forward and is a very valuable
contribution to the Internet community since it updates existing IPFIX
entities to make them consistent, which is for IPFIX data collections
which obtain the information from the IPFIX IANA registry especially
relevant, have references to other registries instead of re-defining
them eases the update procedures in the future and last but not least
updating some of the descriptions due to shortcomings for more
clarity. 

 

I have reviewed the document and wrote the initial shepherd review.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/shepher
dwriteup/

 

I am looking forward for the feedback from the OPSAWG mailing list
wherever ipv6ExtensionHeaders and tcpOptions in favor of
ipv6ExtensionHeadersFull and tcpOptionsFull defined in
draft-ietf-opsawg-ipfix-tcpo-v6eh. Depending on feedback on the
mailing list, a poll at the IETF 119 maybe could be useful as well.

 

ipv6ExtensionHeaders has been adopted by network vendors widely. Where
tcpOptions appears to be,
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DA
qA/, merely used to its ambiguity.

 

I therefore suggest to deprecate tcpOptions. I suggest also
ipv6ExtensionHeaders to deprecate because not all observed extension
headers in a Flow maybe export because of a hardware or software limit
as described in Section 4.1.1 of this document and addressed with
ipv6ExtensionHeadersLimit.

 

As a contributor, I like also to confirm the authors opinions that
forwardingStatus should be unsigned32 instead of unsigned8 not only
because RFC 7270 specifies forwardingStatus as unsigned32, but it
reserves 3 bytes. We have with draft-opsawg-evans-discardmodel and
draft-mvmd-opsawg-ipfix-fwd-exceptions two documents showing interest
to describe the forwarding behavior in IPFIX. We have on OPSAWG
mailing list
https://mailarchive.ietf.org/arch/browse/opsawg/?q=draft-mvmd-opsawg-i
pfix-fwd-exceptions various feedback that an update, extension of
forwardingStatus would be preferred instead of introducing a new IPFIX
entity.

 

Best wishes

Thomas

Orange Restricted

 



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

Re: [OPSAWG] advancing PCAP drafts

2024-02-05 Thread mohamed . boucadair

Hi Michael,

Thanks for the follow-up. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Michael Richardson 
> Envoyé : mercredi 31 janvier 2024 15:10
> À : BOUCADAIR Mohamed INNOV/NET ;
> opsawg@ietf.org
> Objet : Re: [OPSAWG] advancing PCAP drafts
> 
> 
> mohamed.boucad...@orange.com wrote:
> > Hmm...I remember at least the following candidates changes from
> that
> > thread, e.g.,
> 
> > *
> >
> https://mailarchive.ietf.org/arch/msg/opsawg/u0__66zIpCMHA4syzt8fWtyx9
> 8Y/
> > *
> >
> https://mailarchive.ietf.org/arch/msg/opsawg/ExlyBZ9eRP_UHUvCAmtKu0b28
> Z4/
> 
> > I trust that you will check that thread and do the right thing.
> Thanks.
> 
> I've been through that thread.
> I think that I've got it all.
> Please check the diff to -02.

[Med] Thanks. I like the new changes. Please note that there is a bug with the 
table in 3.1.

> 
> I don't know if ISE documents can create registries: one ISE told me
> no.
> The document is in the WG, so let's not religitate that now.

[Med] hmm, I was not reviving that ISE discussion :-( I was actually pointing 
to specific messages with some candidate changes (e.g. tag deprecated entries), 
which you adequately addressed in -02. Thanks. 

> 
> > I sent you right now a PR with some minor edits.
> 
> I believe that it was https://github.com/IETF-OPSAWG-WG/draft-ietf-
> opsawg-pcap/pull/134
> and it was merged nov 9.
> 
> > For the specification required range, you may consider adding some
> guidance for DEs.
> 
> Done.  You may wish to read the diff, and maybe disagree with my
> advice.
> 
> > The initial table does not mirror the current values in
> > https://www.tcpdump.org/linktypes.html. Also, some descriptions in
> the
> > table does not match exactly what is in that table. Not sure if it
> is
> > worth explaining the diff.
> 
> I've updated the table with numbers out to 301.
> I'm not sure about putting URLs in.
> 
> > You may indicate that the procedure for assigning new codes as
> > detailed in https://www.tcpdump.org/linktypes.html won't be followed
> anymore.
> 
> That's been updated in git, and may take a bit to go live.
> 
> > Some assigned types seem to be used for private use while these
> types
> > fall now under a specification required range. I don't know if it is
> > worth to have some consistency here and consider a range for future
> > specification required type, e.g., 300-32767 that won't be mixed
> with the historic ones.
> 
> It's grandfathered as far as I'm concerned.

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] draft-ietf-opsawg-ipfix-tcpo-v6eh updates RFC 7012? 5610? was (Re: I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-09.txt)

2024-02-05 Thread mohamed . boucadair

Hi Benoît,

Good point, but I don't think we need an update here. I suggest this change to 
draft-ietf-opsawg-ipfix-tcpo-v6eh:

OLD:
The type "unsigned256" represents a non-negative integer value in the
range of '0' to '2^256 - 1'.

NEW:
The type "unsigned256" represents a non-negative integer value in the
range of '0' to '2^256 - 1'. This type MUST be encoded as per {{Section 6.1.1 
of !RFC7011}}.

Cheers,
Med

De : Benoit Claise 
Envoyé : lundi 5 février 2024 17:34
À : opsawg@ietf.org
Cc : BOUCADAIR Mohamed INNOV/NET 
Objet : draft-ietf-opsawg-ipfix-tcpo-v6eh updates RFC 7012? 5610? was (Re: 
[OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-09.txt)

Dear all,

With the introduction of new unsigned256  IPFIX data type (section 8.2), I am 
wondering whether draft-ietf-opsawg-ipfix-tcpo-v6eh updates RFC 7012? I guess so

>From RFC7012:




3.1<https://datatracker.ietf.org/doc/html/rfc7012#section-3.1>.  Abstract Data 
Types



   This section describes the set of valid abstract data types of the

   IPFIX information model, independent of encoding.  Note that further

   abstract data types may be specified by future updates to this

   document.  Changes to the associated IPFIX "Information Element Data

   Types" subregistry 
[IANA-IPFIX<https://datatracker.ietf.org/doc/html/rfc7012#ref-IANA-IPFIX>] 
specified in [RFC5610<https://datatracker.ietf.org/doc/html/rfc5610>] require a

   Standards Action [RFC5226<https://datatracker.ietf.org/doc/html/rfc5226>].


Well actually, the registry 
(https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types)
 points to RFC5610
So I guess this document should update both RFC7012 and RF5610.

Initially, I was thinking that an update to RFC 7011 would be necessary, to 
update the following text.
OLD:



6.1.1<https://datatracker.ietf.org/doc/html/rfc7011.html#section-6.1.1>.  
Integral Data Types



   Integral data types -- unsigned8, unsigned16, unsigned32, unsigned64,

   signed8, signed16, signed32, and signed64 -- MUST be encoded using

   the default canonical format in network byte order.  Signed integral

   data types are represented in two's complement notation.



NEW:

6.1.1<https://datatracker.ietf.org/doc/html/rfc7011.html#section-6.1.1>.  
Integral Data Types



   Integral data types -- unsigned8, unsigned16, unsigned32, unsigned64, 
unsigned256

   signed8, signed16, signed32, and signed64 -- MUST be encoded using

   the default canonical format in network byte order.  Signed integral

   data types are represented in two's complement notation.

However, I believe this is not really necessary.

Regards, Benoit
On 1/23/2024 3:24 PM, internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
wrote:

Internet-Draft draft-ietf-opsawg-ipfix-tcpo-v6eh-09.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-09.txt

   Pages:   16

   Dates:   2024-01-23



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-09.html



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-tcpo-v6eh-09



Internet-Drafts are also available by rsync at:

rsync.ietf.org::internet-drafts





___

OPSAWG mailing list

OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>

https://www.ietf.org/mailman/listinfo/opsawg


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

Re: [OPSAWG] [IPFIX] deprecating ipv6ExtensionHeaders and tcpOptions IEs RE: WG LC: IPFIX documents

2024-02-05 Thread mohamed . boucadair

Hi all,

As no objection was raised in the last two weeks, I will tag these two IEs as 
deprecated by the new IEs.

Cheers,
Med

De : Benoit Claise 
Envoyé : lundi 5 février 2024 17:37
À : BOUCADAIR Mohamed INNOV/NET ; Aitken, Paul 
; Joe Clarke (jclarke) 
; opsawg@ietf.org
Cc : ip...@ietf.org
Objet : Re: [IPFIX] deprecating ipv6ExtensionHeaders and tcpOptions IEs RE: WG 
LC: IPFIX documents

Dear all,

Same view here, I believe this is ok.

Regards, Benoit
On 1/23/2024 3:03 PM, 
mohamed.boucad...@orange.com wrote:
Re-,

Paul suggested to tag these two IEs as deprecated in favor of the new full IEs.

I do personally think this is OK (especially given what Andrew reported at: 
https://mailarchive.ietf.org/arch/msg/opsawg/QNm9p8V2vKuhUX5rxBCqcxD-WAY/), but 
would like to hear if there objections to proceed with that path.

Cheers,
Med

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

...

De : ipv6 mailto:ipv6-boun...@ietf.org>> De la part de 
Aitken, Paul
Envoyé : lundi 22 janvier 2024 22:50
À : Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org
Cc : t...@ietf.org; 
ts...@ietf.org; 6...@ietf.org; 
ip...@ietf.org
Objet : Re: [IPv6] [IPFIX] WG LC: IPFIX documents

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes


Consider deprecating this IE in favour of ipv6ExtensionHeadersFull.
[Med]  Seems reasonable, but would like to hear more from the WG.


Consider deprecating this IE in favour of tcpOptionsFull.
[Med] Seems reasonable, but would like to hear more from the WG.






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.



___

IPFIX mailing list

ip...@ietf.org

https://www.ietf.org/mailman/listinfo/ipfix


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] I-D Action: draft-ietf-opsawg-ipfix-fixes-06.txt

2024-02-06 Thread mohamed . boucadair

Hi all, 

This version removes the EH/TCP option IEs as these are now deprecated in favor 
of the IEs defined in draft-ietf-opsawg-ipfix-tcpo-v6eh. Actions to deprecate 
these IEs are discussed in draft-ietf-opsawg-ipfix-tcpo-v6eh.

I think this version is no ready to move forward.

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : mardi 6 février 2024 10:34
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : I-D Action: draft-ietf-opsawg-ipfix-fixes-06.txt
> 
> Internet-Draft draft-ietf-opsawg-ipfix-fixes-06.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-06.txt
>Pages:   35
>Dates:   2024-02-06
> 
> Abstract:
> 
>This document provides simple fixes to the IANA IP Flow Information
>Export (IPFIX) registry.  Specifically, this document provides
>updates to fix a shortcoming in the description of some Information
>Elements (IE), updates to ensure a consistent structure when
> calling
>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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-
> fixes%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca5d7d33ab16f4
> d8b6b9008dc26f6daf7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63842
> 8088874214100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=cBfdSUQn%2BRCpYD
> uQ1xG5UNBXmgC4vuq2HSjU6oehqk0%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ipfix-fixes-
> 06.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca5d7d33ab16f4d
> 8b6b9008dc26f6daf7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638428
> 088874226670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BYUR4mYqE8XWGiv
> FOYE8PkwDoMn7iJocDL7KWHTXcto%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-ipfix-fixes-
> 06&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca5d7d33ab16f4d8b6b9
> 008dc26f6daf7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63842808887
> 4237035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LBYEtARlVXq3T1Sn%2Fn8j
> bvs0NDfY5B6FB9pwVBG4CTw%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> announce&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca5d7d33ab16f4
> d8b6b9008dc26f6daf7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63842
> 8088874247260%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=wsYAPIm7zPh%2FJA
> dm2FTfn7Xxpue7vYsBPPp0oFWBXms%3D&reserved=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] I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-10.txt

2024-02-06 Thread mohamed . boucadair

Hi all, 

This version implements the changes already shared on the list to address 
Paul's review. It also includes new text to deprecate EH/TCP Options IEs.

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : mardi 6 février 2024 10:41
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-10.txt
> 
> Internet-Draft draft-ietf-opsawg-ipfix-tcpo-v6eh-10.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-10.txt
>Pages:   20
>Dates:   2024-02-06
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-tcpo-
> v6eh%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd3a9b7eb0c884b
> da0b4608dc26f7da7e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638428
> 093158417514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ho1FATNSYXpXV3anp
> qPi%2BQqlfwzwoES1f5xNrsVYT1A%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ipfix-tcpo-v6eh-
> 10.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd3a9b7eb0c884b
> da0b4608dc26f7da7e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638428
> 093158427336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sFSveBmXyTetird8H
> %2F8En0bhm%2Bi0KmIkG1bljrh4Dow%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-ipfix-tcpo-v6eh-
> 10&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd3a9b7eb0c884bda0b4
> 608dc26f7da7e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63842809315
> 8437754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HniLmJw8MWHGjCH5FiGYnA
> qifJ8eqPtc09B24uW1%2FOc%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> announce&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd3a9b7eb0c884
> bda0b4608dc26f7da7e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63842
> 8093158448680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ijs%2FGMLE23N0gz
> wiFSkEmhFQ%2FFzBUhKy29z%2F%2FC9ifYQ%3D&reserved=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] [IPv6] [IPFIX] errata eid7775 RE: [EXTERNAL] RE: WG LC: IPFIX documents

2024-02-06 Thread mohamed . boucadair

Hi all,

Bob is right here.

However, the intent of the original text is unambiguous as per the following:

==
Description

  This Information Element describes the forwarding status of the
  flow and any attached reasons.  The reduced-size encoding rules as
  per [RFC7011] apply.

  The basic encoding is 8 bits.  The future extensions
  could add one or three bytes.


Abstract Data Type:  unsigned32
==

Unless an extension is defined, unsigned8 will be used anyway following the 
reduced-encoding in 7011.

Cheers,
Med

De : Bob Hinden 
Envoyé : mardi 6 février 2024 23:48
À : Benoit Claise 
Cc : Bob Hinden ; Andrew Feren ; 
BOUCADAIR Mohamed INNOV/NET ; Aitken, Paul 
; Joe Clarke (jclarke) ; opsawg@ietf.org; 
t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org
Objet : Re: [IPv6] [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX 
documents

Benoit,


On Feb 6, 2024, at 1:12 PM, Benoit Claise 
mailto:benoit.cla...@huawei.com>> wrote:

Hi Bob,
On 2/6/2024 6:18 PM, Bob Hinden wrote:
Benoit,

To clarify, RFC7270  "Cisco-Specific Information Elements  Reused in IP Flow 
Information Export (IPFIX)” is a public RFC published for the Internet 
Community.   Cisco doesn’t have any specific change control over it.
Agreed, but they (Cisco) have to say whether this is an error or not, not the 
community.

I would put it differently.Anyone can report an errata, the Area Directors 
make the decision if the errata is accepted.   That may including checking with 
the authors.   They do not check with the company where the authors worked at 
the time the RFC was published.

Bob





Regards, Benoit


If there are known errors in it, they should be reported in an Errata.  The ADs 
who approve errata will take the correct action.

Bob



On Feb 6, 2024, at 1:19 AM, Benoit Claise 

 wrote:

Hi Andrew,

What the document dated from 2011 mentions does not matter too much.
What is key is the Cisco internal document that contains the Cisco IPFIX 
registry.
So when I wrote " I don't feel comfortable having an errata on a Cisco-specific 
IPFIX", I actually meant: " I don't feel comfortable having an errata on a 
Cisco-specific IPFIX without Cisco approving this".

Regards, Benoit

On 2/5/2024 7:12 PM, Andrew Feren wrote:
Hi Benoit,

I see your point about not having an errata on a Cisco RFC.  That being said….

It appears that the IANA page has listed forwardingStatus(89) as unsigned8 
since 2018.  Also 
CCO-NF9FMT,
 the other cisco document referenced for forwardingStatus(89), is pretty 
unambiguous that forwardingStatus(89) is 1 byte.  Beyond that I don’t have 
strong feelings about this.  The different int sizes never seemed all that 
useful to me anyway since mostly it is the size sent in the template that 
matters.

-Andrew

From: IPFIX  on behalf 
of Benoit Claise 

Date: Monday, February 5, 2024 at 12:37 PM
To: mohamed.boucad...@orange.com 
, Aitken, 
Paul , Joe Clarke (jclarke) 
, 
opsawg@ietf.org 

Cc: t...@ietf.org , 
ts...@ietf.org , 
6...@ietf.org <6...@ietf.org>, 
ip...@ietf.org 
Subject: Re: [IPFIX] errata eid7775 RE: [**EXTERNAL**] RE: WG LC: IPFIX 
documents
[EXTERNAL] CAUTION: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender and know 
the content is safe.

Hi Paul,
On 1/23/2024 12:14 PM, 
mohamed.boucad...@orange.com wrote:
4.3.  forwardingStatus

In particular, the registered Abstract
   Data Type is unsigned8, while it must be unsigned32.

Why must it be?
[Med] As per the definition in RFC7270.

I've opened an errata for that: https://www.rfc-editor.org/errata/eid7775
[Med] I don’ think an erratum applies here because the intent of 7270 is 
clearly unsigned32:

While you and I were working on NetFlow at Cisco when we wrote the RFC 7270, I 
don't feel comfortable having an errata on a Cisco-specific IPFIX.
Anyway, what is the issue with keeping unsigned32, should we be liberal in what 
we accept?
And we know that the reduced-size encoding 
(https://datatracker.ietf.org/doc/html/rfc7011.html#section-6.2) will be used 
anyway. It's not even useful to have this sentence ("
IPFIX reduced-size encoding is used as required") in the description but I can 
live with it.

Regards, Benoit



This email message and any attachments are confidential. If you are not the 
intended recipient, plea

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

Hi Martin, all, 

FWIW, the proposed changes are now implemented in the public version: 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ac-lxsm-lxnm-glue-06.

Cheers,
Med 

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : jeudi 25 janvier 2024 13:56
> À : 'Martin Björklund' 
> Cc : yang-doct...@ietf.org; draft-ietf-opsawg-ac-lxsm-lxnm-
> glue@ietf.org; opsawg@ietf.org
> Objet : RE: Yangdoctors early review of draft-ietf-opsawg-ac-lxsm-
> lxnm-glue-04
> 
> Hi Martin,
> 
> Thank you for the follow-up.
> 
> Fixed the nits in the yang file. Also updated the module to make use
> of the new groupings for referencing purposes instead of the broken
> typedefs in the ac-ntw:
> 
> https://author-tools.ietf.org/api/iddiff?iddiff?doc_1=draft-ietf-
> opsawg-ac-lxsm-lxnm-glue&url_2=https://boucadair.github.io/attachment-
> circuit-model/boucadair-patch-5/draft-ietf-opsawg-ac-lxsm-lxnm-
> glue.txt
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Martin Björklund  Envoyé : mercredi 24
> janvier
> > 2024 16:52 À : BOUCADAIR Mohamed INNOV/NET
> >  Cc : yang-doct...@ietf.org;
> > draft-ietf-opsawg-ac-lxsm-lxnm- glue@ietf.org; opsawg@ietf.org
> > Objet : Re: Yangdoctors early review of draft-ietf-opsawg-ac-lxsm-
> > lxnm-glue-04
> >
> > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> > > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-ac-lxsm-
> lxnm-
> > glu
> > > e-
> > 05&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C46a62fe529bd44020
> > >
> >
> 91308dc1cf473e7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638417083
> > >
> >
> 964251050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> > >
> >
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C41000%7C%7C%7C&sdata=ZWGtBagO6Z2BiYEH
> > > xG8yqYJwwzj72LPLDoUVEKRHM2U%3D&reserved=0
> >
> > 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.

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

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

Hi all, 

FWIW, the proposed changes are now implemented in the published version: 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ntw-attachment-circuit-05.

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : jeudi 25 janvier 2024 13:46
> À : 'Martin Björklund' ; yang-doct...@ietf.org
> Cc : draft-ietf-opsawg-ntw-attachment-circuit@ietf.org;
> opsawg@ietf.org
> Objet : RE: Yangdoctors early review of draft-ietf-opsawg-ntw-
> attachment-circuit-04
> 
> Hi Martin,
> 
> Thanks for the review.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Martin Björklund via Datatracker  Envoyé :
> > mercredi 24 janvier 2024 16:20 À : yang-doct...@ietf.org Cc :
> > draft-ietf-opsawg-ntw-attachment-circuit@ietf.org;
> > opsawg@ietf.org
> > Objet : Yangdoctors early review of draft-ietf-opsawg-ntw-
> attachment-
> > circuit-04
> >
> > 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).
> >
> 
> [Med] Good catch. We don't have that constraint on the "ac-ntw:name".
> Please see the candidate changes to fix this at: https://author-
> tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment
> -circuit-model/draft-ietf-opsawg-ntw-attachment-
> circuit.txt&url_2=https://boucadair.github.io/attachment-circuit-
> model/boucadair-patch-5/draft-ietf-opsawg-ntw-attachment-circuit.txt.
> The use of groupings for references is consistent with the approach in
> RFC 8345.
> 
> >
> > 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";
> >
> 
> [Med] Fixed.
> 
> >
> > 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.
> >
> 
> [Med] Agree. Fixed.
> 
> >
> > o  Some lists have plural-names: routing-profiles, ipv4-lan-
> prefixes,
> >ipv6-lan-prefixes.  Usually lists should have singular names.
> >
> 
> [Med] Fixed.
> 
> > 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)
> >
> >
> 
> [Med] Works for me. Thanks.
> 
> >
> > /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] I-D Action: draft-ietf-opsawg-teas-common-ac-05.txt

Hi all, 

The main change in -05 is adding a new identity for BGP capabilities, which we 
need at the network level in particular. 

We don't have any open issue of this spec.

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de internet-
> dra...@ietf.org
> Envoyé : vendredi 9 février 2024 13:32
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : [OPSAWG] I-D Action: draft-ietf-opsawg-teas-common-ac-05.txt
> 
> Internet-Draft draft-ietf-opsawg-teas-common-ac-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 Common YANG Data Model for Attachment Circuits
>Authors: Mohamed Boucadair
> Richard Roberts
> Oscar Gonzalez de Dios
> Samier Barguil Giraldo
> Bo Wu
>Name:draft-ietf-opsawg-teas-common-ac-05.txt
>Pages:   53
>Dates:   2024-02-09
> 
> Abstract:
> 
>The document specifies a common Attachment Circuits (ACs) YANG
>module, which is designed with the intent to be reusable by other
>models.  For example, this common model can be reused by service
>models to expose ACs as a service, service models that require
>binding a service to a set of ACs, network and device models to
>provision ACs, etc.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-teas-common-
> ac%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdbbd71c3ee7640c7
> 091008dc296b1224%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63843078
> 7049955855%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UfYHciXlSb7vqip7fka
> pU%2F0SGfPGvdUrxyA1VsCGd9M%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-teas-common-ac-
> 05.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdbbd71c3ee7640
> c7091008dc296b1224%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638430
> 787049965108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LBTNtig6sNFBNnFVa
> XoXixiNUjTgV%2BK8N1a2ijC1JMw%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-teas-common-ac-
> 05&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdbbd71c3ee7640c7091
> 008dc296b1224%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63843078704
> 9971600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PkY874LogJ0sYpu9hry4UD
> 5EzeX1CkJOrkJMdgR6cvI%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=05%7C02%7Cmohamed.boucadai
> r%40orange.com%7Cdbbd71c3ee7640c7091008dc296b1224%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C638430787049976425%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=ZbNOAJuSlLTvqbd9m7Pr84wz7SyE0pVKJDtDcDUEthA%3D&reserved=
> 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] I-D Action: draft-ietf-opsawg-teas-attachment-circuit-06.txt

Hi all, 

The main changes in this version are as follows: 

* Support of lag (bearer, level)
* Child bearers can be listed under a parent bearer (as read-only)
* A parent AC can list its child as read-only 
* bfd profile can be called at the routing level, not only centralized at the 
OAM level
* Add a new example

We are planning to add some other few examples to illustrate the use of the 
model. We hope to finalize those soon.

Please review and share your comments.

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : vendredi 9 février 2024 15:23
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : I-D Action: draft-ietf-opsawg-teas-attachment-circuit-06.txt
> 
> Internet-Draft draft-ietf-opsawg-teas-attachment-circuit-06.txt is now
> available. It is a work item of the Operations and Management Area
> Working Group (OPSAWG) WG of the IETF.
> 
>Title:   YANG Data Models for Bearers and 'Attachment Circuits'-as-
> a-Service (ACaaS)
>Authors: Mohamed Boucadair
> Richard Roberts
> Oscar Gonzalez de Dios
> Samier Barguil Giraldo
> Bo Wu
>Name:draft-ietf-opsawg-teas-attachment-circuit-06.txt
>Pages:   109
>Dates:   2024-02-09
> 
> Abstract:
> 
>This document specifies a YANG service data model for Attachment
>Circuits (ACs).  This model can be used for the provisioning of ACs
>before or during service provisioning (e.g., Network Slice
> Service).
>The document also specifies a service model for managing bearers
> over
>which ACs are established.
> 
>Also, the document specifies a set of reusable groupings.  Whether
>other service models reuse structures defined in the AC models or
>simply include an AC reference is a design choice of these service
>models.  Utilizing the AC service model to manage ACs over which a
>service is delivered has the advantage of decoupling service
>management from upgrading AC components to incorporate recent AC
>technologies or features.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-teas-attachment-
> circuit%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C70d86eeb88e
> 041aa069e08dc297a9cc2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> 430853790873527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3xH43Nyh5%2FuS
> HzONkrWwbxb8qZBNp1TDYtQG9dcv8Yk%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-teas-attachment-circuit-
> 06.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C70d86eeb88e041
> aa069e08dc297a9cc2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638430
> 853790883602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fxNyW0J6SQzZ26%2F
> xQdnmYH5OTUedwpdF3pUjb33xfsc%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-teas-attachment-
> circuit-
> 06&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C70d86eeb88e041aa069
> e08dc297a9cc2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63843085379
> 0891263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=0U36O2amtinHwKmr%2BkbQ
> cBdr4p1nDB7xlE4aLfDEMko%3D&reserved=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] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

2024-02-23 Thread mohamed . boucadair

Hi Paul,

Unless I'm mistaken, I didn't see any follow-up to this issue.

May I consider this point as closed? Thanks.

Cheers,
Med

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

Hi Paul,

> It is consistent but wrong, as the numeric value of these fields is 
> meaningless. Bitfields with flags semantics don't have a meaningful 
> "unsigned" value.

You raised this comment for both TCP/UDP specs.

As I mentioned in the previous message, all existing IEs of type flags are 
using an unsigned type. Also, please note that rfc7012#section-3.2.5 says the 
followings:

   "flags" is an integral value that represents a set of bit fields.
   Logical operations are appropriate on such values, but other
   mathematical operations are not.  Flags MUST always be of an unsigned
   data type.

And rfc7012#section-3:

   Abstract data types unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and signed64 are integral data types.
   As described in Section 3.2, their data type semantics can be further

   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier', or 'flags'.
 ^^

I quite don't understand why we need to define Bitfields rather than leveraging 
on the approach followed so far in IPFIX.

Cheers,
Med

De : Aitken, Paul mailto:pait...@ciena.com>>
Envoyé : lundi 22 janvier 2024 11:49
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; Aitken, 
Paul 
mailto:paitken=40ciena@dmarc.ietf.org>>;
 Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org
Cc : t...@ietf.org; 
ts...@ietf.org; 6...@ietf.org; 
ip...@ietf.org
Objet : Re: Re: [IPFIX] WG LC: IPFIX documents

Med,

   The IE specified in Section 4.1 uses the new abstract data type
   defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

The unsigned256 type? It makes more sense to introduce a bitfield type.
[Med] I think the use of unsigned256 is consistent with the current use in IP 
Flow Information Export (IPFIX) Entities (iana.org) 
[iana.org]
 (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs 
having data semantic of flags.

It is consistent but wrong, as the numeric value of these fields is 
meaningless. Bitfields with flags semantics don't have a meaningful "unsigned" 
value.

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] octetArray/hextetArray/32tetArray RE: Re: [IPFIX] WG LC: IPFIX documents

2024-02-23 Thread mohamed . boucadair

Hi Paul,

Do you still think there is an issue with the design? Thanks.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 23 janvier 2024 14:56
À : 'Aitken, Paul' ; Joe Clarke (jclarke) 
; opsawg@ietf.org
Cc : ip...@ietf.org
Objet : octetArray/hextetArray/32tetArray RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

(restricted the distribution lists to OPSAWG and IPFIX)

The octetArray type is especially confusing as these are really hextetArrays.

[Med] Not sure we need a new data type here as octeArray is defined as follows:
   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.

The draft proposes the encoding not of octets, but of 16-bit values. Therefore 
it's not an "array of zero or more octets" but rather, an "array of zero or 
more hextets".

[Med] I was assuming that «interpretation of the octets defined in the 
Information Element definition" in the excerpt is not restrictive and leave it 
to the definition of the IE to determine how to interpret the octets (including 
when grouping them into 16 bits, 32 bits, etc.). Given that interpreting the 
data requires anyway digesting the structure in the definition not only the 
abstract data type, I thought that we don't need to define new types for 
specific octet- blocks, but I may be mistaken.

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] RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit

2024-03-10 Thread mohamed . boucadair

Hi Donald,

(adding OPSAWG as it seems the review was not shared on that list)

Thanks for the careful review.

A diff to track the changes to address your comments can be seen at:

https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-teas-attachment-circuit&url_2=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt

See more context inline, fwiw.

Cheers,
Med

De : Donald Eastlake
Envoyé : samedi 9 mars 2024 04:16
À : teas-cha...@ietf.org; draft-ietf-opsawg-teas-attachment-circuit@ietf.org
Cc : Routing Directorate ; t...@ietf.org
Objet : RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit

Hello,

I have been selected to do a routing directorate "early" review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/

The routing directorate will, on request from the working group chair, perform
an "early" review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft's lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document has recently been adopted by the working group fairly recently
(November 2023), my focus for the review is on catching any issues early on in
the document's life cycle.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-opsawg-teas-attachment-circuit-07.txt
Reviewer: Donald Eastlake
Review Date: 8 March 2024
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

This document specifies a YANG service data model for Attachment Circuits and a
set of reusable groupings. I am not that deep a YANG expert but it seems to be
headed in the right direction.

Comments:
-

I found the writing in this draft to be reasonably good in quality and
readability.

It seems curious that the first sentence of Section 1.1 does not mention PEs.
[Med] That list focuses on the customer terminating points, not the
network-facing ones. Added a PE mention in the para when provider network is
mentioned.

Also, Service Functions (and Service Function Forwarders?) seem to usually be
listed first in such lists giving them great importance.
[Med] SF is mentioned (and changed all occurrences of network function to SF
for consistency). No need to call out SFF.

In Section 3.2, I don't think "advanced network services", which sounds like a
marketing term, is well defined. If you mean network slicing, just say that.
[Med] Reworded.

The list of references to section 4.2.5.3.x at the start of the 2nd paragraph
of Section 4.2.5.3 is missing VRRP (Section 4.2.5.6).
[Med] Added a new sentence to mention VRRP.

Except that actually a number of the sections seem like they should be one
level deeper: 4.2.5.4 -> 4.2.5.3.4, 4.2.5.5 -> 4.2.3.5, and 4.2.5.6 ->
4.2.5.3.6. This would change the numbering of a few following sections such as
4.2.5.7 -> 4.2.5.4.
[Med] Good catch. Fixed.

Figure 11 seems to be missing ospf.
[Med] You are right. Fixed.

In Section 6 there are two sentences that begin "These data nodes are defined
with ". It is not clear to me if "These" refers to the nodes listed before or
those listed after the sentence.
[Med] Reworded to clarify the intent.

Nits:
[Med] Went with almost all your suggestions. Please note that I didn't add a
ref to RFC20 given that we provide the authoritative reference RFC8177 for key
strings. I also didn't change to vrrp-bis for now. Will take care of that when
the RFC is published.

"merit to decorrelate the" -> "merit of decorrelating the"

"An example to retrieve a" -> "An example of retrieving a"

"SAPs" is not spelled out where first used but rather in the following
paragraph.

"the ACs that the ordered" -> "the ACs that they ordered"

"If these provisioning of these services require specific" -> "If the
provisioning of these services requires"

Section 1.2 heading: "Position" -> "Positioning"

Section 1.2.1 and 1.2.2 headings: "Using" -> "Use"

"L2SM" and "L3SM" are not expanded.

Section 3.1, Since "VRRP" is used and expanded, a reference to
draft-ietf-rtgwg-vrrp-rfc5798bis-18 would be appropriate. (That draft is in the
RFC Editor queue in the final stage of editing so should not become a blocking
reference.)

In Figures 1, 35, 36, and 40, vertical lines are usually represented by the
ASCII VERTICAL LINE character, 0x7C, which is what is normally used in ASCII
art, but in some cases the Unicode character BOX DRAWINGS LIGHT VERTICAL,
0x2502, is used. This causes garbles in the htmlized version of the draft. I
recommend a global replacement of character 0x2502 with character 0x7C and, in
any case, they should be consistent.

In the first line after the Figure 3 caption, there is an "NF",

Re: [OPSAWG] RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit

2024-03-16 Thread mohamed . boucadair

Hi Donald,

FYI, the changes are now published as -08.

Thank you.

Cheers,
Med

De : Donald Eastlake
Envoyé : mardi 12 mars 2024 03:05
À : BOUCADAIR Mohamed INNOV/NET
Cc : opsawg@ietf.org; draft-ietf-opsawg-teas-attachment-circuit@ietf.org;
Routing Directorate ; t...@ietf.org
Objet : Re: RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit

Hi Med,

I have reviewed the changes you made and am happy with them. I consider all my
comments to have been resolved.

Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com

On Mon, Mar 11, 2024 at 2:31 AM
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Donald,

(adding OPSAWG as it seems the review was not shared on that list)

Thanks for the careful review.

A diff to track the changes to address your comments can be seen at:

https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-teas-attachment-circuit&url_2=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt

See more context inline, fwiw.

Cheers,
Med

De : Donald Eastlake mailto:d3e...@gmail.com>>
Envoyé : samedi 9 mars 2024 04:16
À : teas-cha...@ietf.org;
draft-ietf-opsawg-teas-attachment-circuit@ietf.org
Cc : Routing Directorate mailto:rtg-...@ietf.org>>;
t...@ietf.org
Objet : RTGDIR Early Review of draft-ietf-opsawg-teas-attachment-circuit

Hello,

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document has recently been adopted by the working group fairly recently
(November 2023), my focus for the review is on catching any issues early on in
the document's life cycle.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-opsawg-teas-attachment-circuit-07.txt
Reviewer: Donald Eastlake
Review Date: 8 March 2024
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

This document specifies a YANG service data model for Attachment Circuits and a
set of reusable groupings. I am not that deep a YANG expert but it seems to be
headed in the right direction.

Comments:
-

I found the writing in this draft to be reasonably good in quality and
readability.

In Section 3.2, I don't think "advanced network services", which sounds like a
marketing term, is well defined. If you mean network slicing, just say that.
[Med] Reworded.

The list of references to section 4.2.5.3.x at the start of the 2nd paragraph
of Section 4.2.5.3 is missing VRRP (Section 4.2.5.6).
[Med] Added a new sentence to mention VRRP.

Figure 11 seems to be missing ospf.
[Med] You are right. Fixed.

Nits:
[Med] Went with almost all your suggestions. Please note that I didn’t add a
ref to RFC20 given that we provide the authoritative reference RFC8177 for key
strings. I also didn’t change to vrrp-bis for now. Will take care of that when
the RFC is published.

"merit to decorrelate the" -> "merit of decorrelating the"

"An example to retrieve a" -> "An example of retrieving a"

"SAPs" is not spelled out where first used but rather in the following
paragraph.

"the ACs that the ordered" -> "the ACs that they ordered"

"If these provisioning of these services require specific" -> "

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-teas-common-ac-05

2024-03-21 Thread mohamed . boucadair

Hi Andy, 

Thank you for the review. Much appreciated.

Your review will be acked in next iteration of the spec: 
https://github.com/boucadair/attachment-circuit-model/commit/7de5b2ad817cb61813ef896885b2296d00d002bc

Cheers,
Med

> -Message d'origine-
> De : Andy Smith via Datatracker 
> Envoyé : vendredi 22 mars 2024 04:20
> À : rtg-...@ietf.org
> Cc : draft-ietf-opsawg-teas-common-ac@ietf.org; opsawg@ietf.org
> Objet : Rtgdir early review of draft-ietf-opsawg-teas-common-ac-05
> 
> Reviewer: Andy Smith
> Review result: Ready
> 
> Draft is well written and easy to understand.   It solves a problem
> that is
> understood.   I see no reason it shouldn't proceed.
> 


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] Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

2024-04-01 Thread mohamed . boucadair

Hi Gyan, 

Thank you for the review. 

The candidate revisions can be tracked here: 

* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-common-ac.diff
* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-attachment-circuit.diff
* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ntw-attachment-circuit.diff
* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ac-lxsm-lxnm-glue.diff

See more context inline. 

Cheers,
Med

> -Message d'origine-
> De : Gyan Mishra via Datatracker 
> Envoyé : vendredi 29 mars 2024 18:05
> À : rtg-...@ietf.org
> Cc : draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org; opsawg@ietf.org
> Objet : Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
> 
> 
> Reviewer: Gyan Mishra
> Review result: Has Issues
> 
> I have been selected as the Routing Area Directorate Reviewer for the
> draft
> below:
> 
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
> 
> I reviewed the latest version 6 and the ideas behind the concept of
> the draft makes sense, however some additional recommendations on
> clarity of the draft I believe is necessary before publication.
> 
> This draft was presented at IETF 117 last summer by Mohamed Boucadair
> and adopted on November 6th 2023.  As the draft was adopted fairly
> recently, my goal is to catch any issues with the draft before
> publication.
> 
> The 3 additional drafts below were reviewed together as requested.
> 
> ! Draft being reviewed
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
> 
> ! Additional drafts reviewed
> draft-ietf-opsawg-ntw-attachment-circuit-05
> draft-ietf-opsawg-teas-attachment-circuit-06
> draft-ietf-opsawg-teas-common-ac-05
> 
> All 4 drafts were adopted on November 6th 2023.
> 
> I ran IDNITS against all 4 drafts and result was “no issues found
> here”
> 
> Routing Area Directorate Review request Main Draft
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
> 
> Major Issues:
> None
> 
> Minor Issues:
> The main use case for this draft is for network slicing

[Med] Actually, no. This draft focuses on binding LxVPN to ACs. The required 
functionality to bind a slice service with ACs is built as part of the service 
slice model itself. FWIW, draft-ietf-teas-ietf-network-slice-nbi-yang includes 
the following:

   *  "ac-svc-name": Indicates the names of AC services, for association
  purposes, to refer to the ACs that have been created.  When both
  "ac-svc-name" and the attributes of "attachment-circuits" are
  defined, the "ac-svc-name" takes precedence.

 | +--rw ac-svc-name*  string
 | +--rw attachment-circuits
 | |  +--rw attachment-circuit* [id]
 | | +--rw id   string
 | | +--rw description? string
 | | +--rw ac-svc-name? string

 that is to be
> used as discussed in TEAS WG IETF 117 by author Mohamed Boucadair.  As
> that is the main use case I wonder if it makes sense to add that to
> the introduction.  RFC 8466 L2SM, RFC 8299 L3SM Service modules were
> published in 2018 and RFC 9291 L2NM, RFC 9182 L3NM were published in
> 2022.  So it has been pretty recent since the Network Modules have
> been published but not as recent for the Service modules.
> The idea and concept of an AC or AC Glue has not been developed until
> just this past November.  As Network slicing is the main use case for
> the glue model would it be possible to add Network slicing as the
> example in Appendix A.

[Med] We already have such example in 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-08#name-binding-attachment-circuits
 (Figure 40), where this makes more sense.

  Do you see in the future a Yang Data model for
> the examples mentioned in Appendix A.  Also if the other examples are
> not as likely to be used would it make sense to remove.
> 
> With this draft AFAIK are we really trying to show with the yang model
> the main use case for this draft to be network slicing.
> 
> I think it would be relevant to add the Network Slicing framework RFC
> 9543 as an informative reference.

[Med] I'm afraid no. see the reasons above.

> 
> The Network Slicing NBI Yang Data model provides the Yang Data model
> for Network Slice Services for all the connectivity constructs defined
> in the network slicing framework draft for provisioning network
> slicing for “ac-svc”
> services.   So what is the gap that these 4 drafts provide that is
> missing  for
> Network Slicing that is not provided by the Network Slice NBI Yang
> Data model draft below.

[Med] There is no gap to fill for slicing as we have

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ntw-attachment-circuit-05

2024-04-01 Thread mohamed . boucadair

Hi Gyan, 

Thanks for the review. 

I think all these comments were replied to in: 
https://mailarchive.ietf.org/arch/msg/rtg-dir/EMYA94T2AcU58UMmnNPm7qxCm6c/

Cheers,
Med

> -Message d'origine-
> De : Gyan Mishra via Datatracker 
> Envoyé : vendredi 29 mars 2024 17:59
> À : rtg-...@ietf.org
> Cc : draft-ietf-opsawg-ntw-attachment-circuit@ietf.org;
> opsawg@ietf.org
> Objet : Rtgdir early review of draft-ietf-opsawg-ntw-attachment-
> circuit-05
> 
> Reviewer: Gyan Mishra
> Review result: Has Issues
> 
> I reviewed the latest version 5 and the ideas behind the concept of
> the draft makes sense, however some additional recommendations on
> clarity of the draft I believe is necessary before publication.
> 
> This draft was presented at IETF 117 last summer by Mohamed Boucadair
> and adopted on November 6th 2023.  As the draft was adopted fairly
> recently, my goal is to catch any issues with the draft before
> publication.
> 
> The 3 additional drafts below were reviewed together as requested.
> 
> ! Draft being reviewed
> draft-ietf-opsawg-ntw-attachment-circuit-05
> 
> ! Additional drafts reviewed
> draft-ietf-opsawg-teas-attachment-circuit-06
> draft-ietf-opsawg-teas-common-ac-05
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
> 
> I ran IDNITS against all 4 drafts and result was “no issues found
> here”
> 
> All 4 drafts were adopted on November 6th 2023.
> 
> Routing Area Directorate Review request Main Draft
> draft-ietf-opsawg-ntw-attachment-circuit-05
> 
> Major Issues:
> None
> 
> Minor Issues:
> I would recommend showing how all 4 drafts work together in each of
> the 4 drafts as they all work together to provide the overall AC
> solution.
> 
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
> draft-ietf-opsawg-ntw-attachment-circuit-05
> draft-ietf-opsawg-teas-attachment-circuit-06
> draft-ietf-opsawg-teas-common-ac-05
> 
> Is there any way to merge some of these drafts together or do they all
> have to be separate. It makes it difficult for the reader to follow
> the solution.
> 
> What does “ntw” mean please expand.
> 
> This draft has routing section 4.6 for bgp, ospf, isis, rip, vrrp
> (static is
> missing)
> 
> Could the routing protocols section just refer to L3NM L3SM RFC for
> any details on the routing protocol necessary or point to the LXNM
> Glue draft that glues 4
> NM & SM modules together.   I think that would simplify the draft so
> not
> providing redundant yang data models that has already been documented
> in other RFCs.
> 
> Section 4.4 L2 connection & Section 4.5 IP connection and then 4.6
> goes into detail about each routing protocol however there is no
> corresponding detailed section for L2 services as there is for L3
> services on the AC.
> 
> Nits:
> None
> 
> ! Additional drafts reviewed
> draft-ietf-opsawg-teas-attachment-circuit-06
> 
> Major Issues:
> None
> 
> Minor Issues:
> 
> This draft has routing section 4.2.5.3 for static, bgp, ospf, isis,
> rip, vrrp
> 
> Could the routing protocols section just refer to L3NM L3SM RFC for
> any details on the routing protocol necessary or point to the LXNM
> Glue draft that glues 4
> NM & SM modules together.   I think that would simplify the draft so
> not
> providing redundant yang data models that has already been documented
> in other RFCs.
> 
> I would recommend showing how all 4 drafts work together in each of
> the 4 drafts as they all work together to provide the overall AC
> solution.
> 
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
> draft-ietf-opsawg-ntw-attachment-circuit-05
> draft-ietf-opsawg-teas-attachment-circuit-06
> draft-ietf-opsawg-teas-common-ac-05
> 
> Is there any way to merge some of these drafts together or do they all
> have to be separate. It makes it difficult for the reader to follow
> the solution.
> 
> Nits:
> Remove all the bold of lines within the draft.  AFAIK it makes it
> difficult for the user to read.
> 
> ! Additional drafts reviewed
> draft-ietf-opsawg-teas-common-ac-05
> 
> Major Issues:
> None
> 
> Minor Issues:
> 
> Is the goal of this draft to take items that are common between all
> ACs for the L2NM & L2SM modules.  Why not make this part of one of the
> other drafts like the ac-glue or even the ACAAS draft.
> 
> I would recommend showing how all 4 drafts work together in each of
> the 4 drafts as they all work together to provide the overall AC
> solution.
> 
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
> draft-ietf-opsawg-ntw-attachment-circuit-05
> draft-ietf-opsawg-teas-attachment-circuit-06
> draft-ietf-opsawg-teas-common-ac-05
> 
> Is there any way to merg

Re: [OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

2024-04-02 Thread mohamed . boucadair

Hi all,

As indicated in IETF#119, we suggest to tag this issue as closed and proceed 
with the publication of the current versions of the various I-Ds.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : vendredi 23 février 2024 15:55
À : 'Aitken, Paul' ; 'Joe Clarke (jclarke)' 
; 'opsawg@ietf.org' 
Cc : 'ip...@ietf.org' 
Objet : RE: Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

Unless I'm mistaken, I didn't see any follow-up to this issue.

May I consider this point as closed? Thanks.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 23 janvier 2024 14:23
À : 'Aitken, Paul' mailto:pait...@ciena.com>>; Aitken, Paul 
mailto:paitken=40ciena@dmarc.ietf.org>>;
 Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org
Cc : t...@ietf.org; 
ts...@ietf.org; 6...@ietf.org; 
ip...@ietf.org
Objet : Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

> It is consistent but wrong, as the numeric value of these fields is 
> meaningless. Bitfields with flags semantics don't have a meaningful 
> "unsigned" value.

You raised this comment for both TCP/UDP specs.

As I mentioned in the previous message, all existing IEs of type flags are 
using an unsigned type. Also, please note that rfc7012#section-3.2.5 says the 
followings:

   "flags" is an integral value that represents a set of bit fields.
   Logical operations are appropriate on such values, but other
   mathematical operations are not.  Flags MUST always be of an unsigned
   data type.

And rfc7012#section-3:

   Abstract data types unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and signed64 are integral data types.
   As described in Section 3.2, their data type semantics can be further

   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier', or 'flags'.
 ^^

I quite don't understand why we need to define Bitfields rather than leveraging 
on the approach followed so far in IPFIX.

Cheers,
Med

De : Aitken, Paul mailto:pait...@ciena.com>>
Envoyé : lundi 22 janvier 2024 11:49
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; Aitken, 
Paul 
mailto:paitken=40ciena@dmarc.ietf.org>>;
 Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org
Cc : t...@ietf.org; 
ts...@ietf.org; 6...@ietf.org; 
ip...@ietf.org
Objet : Re: Re: [IPFIX] WG LC: IPFIX documents

Med,
   The IE specified in Section 4.1 uses the new abstract data type
   defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

The unsigned256 type? It makes more sense to introduce a bitfield type.
[Med] I think the use of unsigned256 is consistent with the current use in IP 
Flow Information Export (IPFIX) Entities (iana.org) 
[iana.org]
 (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs 
having data semantic of flags.

It is consistent but wrong, as the numeric value of these fields is 
meaningless. Bitfields with flags semantics don't have a meaningful "unsigned" 
value.

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] ac-svc-name/attachment-circuit (was RE: Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06)

2024-04-03 Thread mohamed . boucadair

Hi Mahesh,

(changing the subject as this point is related to a teas WG doc + adding teas
mailing list)

A choice would be intuitive here. However, a case it might be useful to have
both rather than a choice is to handle migration cases. For example, a slice
service was first bound to a very basic dedicated AC, but then the management
of that AC is handed to the ACaaS because the AC is shared between several
services. But, one would argue that the basic AC can also be created using
ACaaS, which is fair as well.

I let the authors of draft-ietf-teas-ietf-network-slice-nbi-yang clarify the
intended usage. Independent of whether the current design is maintained or a
choice is used, some text to explain the design rationale would be helpful in
the spec.

Thank you.

Cheers,
Med

De : Mahesh Jethanandani
Envoyé : mardi 2 avril 2024 23:09
À : BOUCADAIR Mohamed INNOV/NET
Cc : Gyan Mishra ; rtg-...@ietf.org;
draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org; opsawg@ietf.org
Objet : Re: Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

Hi Med,

Just one comment. See inline with [mj]

On Apr 1, 2024, at 11:05 PM,
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:

Hi Gyan,

Thank you for the review.

The candidate revisions can be tracked here:

*
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-common-ac.diff
*
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-attachment-circuit.diff
*
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ntw-attachment-circuit.diff
*
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ac-lxsm-lxnm-glue.diff

See more context inline.

Cheers,
Med

-Message d'origine-
De : Gyan Mishra via Datatracker mailto:nore...@ietf.org>>
Envoyé : vendredi 29 mars 2024 18:05
À : rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Cc :
draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org<mailto:draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org>;
opsawg@ietf.org<mailto:opsawg@ietf.org>
Objet : Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

Reviewer: Gyan Mishra
Review result: Has Issues

I have been selected as the Routing Area Directorate Reviewer for the
draft
below:

draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

I reviewed the latest version 6 and the ideas behind the concept of
the draft makes sense, however some additional recommendations on
clarity of the draft I believe is necessary before publication.

This draft was presented at IETF 117 last summer by Mohamed Boucadair
and adopted on November 6th 2023. As the draft was adopted fairly
recently, my goal is to catch any issues with the draft before
publication.

The 3 additional drafts below were reviewed together as requested.

! Draft being reviewed
draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

! Additional drafts reviewed
draft-ietf-opsawg-ntw-attachment-circuit-05
draft-ietf-opsawg-teas-attachment-circuit-06
draft-ietf-opsawg-teas-common-ac-05

All 4 drafts were adopted on November 6th 2023.

I ran IDNITS against all 4 drafts and result was "no issues found
here"

Routing Area Directorate Review request Main Draft
draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

Major Issues:
None

Minor Issues:
The main use case for this draft is for network slicing

[Med] Actually, no. This draft focuses on binding LxVPN to ACs. The required
functionality to bind a slice service with ACs is built as part of the service
slice model itself. FWIW, draft-ietf-teas-ietf-network-slice-nbi-yang includes
the following:

* "ac-svc-name": Indicates the names of AC services, for association
purposes, to refer to the ACs that have been created. When both
"ac-svc-name" and the attributes of "attachment-circuits" are
defined, the "ac-svc-name" takes precedence.

[mj] Is there a reason to have both? Should it not be a choice statement?

This message and its attachments may contain confidential or privileged
information that may be prot

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

2024-04-04 Thread mohamed . boucadair

Hi Gyan,

Thank you.

The new versions that address your review are now published.

Cheers,
Med

De : Gyan Mishra 
Envoyé : jeudi 4 avril 2024 09:35
À : BOUCADAIR Mohamed INNOV/NET 
Cc : draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org; opsawg@ietf.org; 
rtg-...@ietf.org
Objet : Re: Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06


Hi Med



I reviewed the updates in the -latest version with each draft having a section 
3 added "Relationship to other AC data models" is perfect.

I believe this 4 draft solution for AC provisioning  decoupling the bearer from 
the services will be very helpful for network slicing provisioning as well as 
other future use cases for AC work.

This draft is ready for publication.

Thank you



Gyan




On Tue, Apr 2, 2024 at 2:06 AM 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Gyan,

Thank you for the review.

The candidate revisions can be tracked here:

* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-common-ac.diff
* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-attachment-circuit.diff
* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ntw-attachment-circuit.diff
* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ac-lxsm-lxnm-glue.diff

See more context inline.

Cheers,
Med

> -Message d'origine-
> De : Gyan Mishra via Datatracker mailto:nore...@ietf.org>>
> Envoyé : vendredi 29 mars 2024 18:05
> À : rtg-...@ietf.org<mailto:rtg-...@ietf.org>
> Cc : 
> draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org<mailto:draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org>;
>  opsawg@ietf.org<mailto:opsawg@ietf.org>
> Objet : Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
>
>
> Reviewer: Gyan Mishra
> Review result: Has Issues
>
> I have been selected as the Routing Area Directorate Reviewer for the
> draft
> below:
>
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
>
> I reviewed the latest version 6 and the ideas behind the concept of
> the draft makes sense, however some additional recommendations on
> clarity of the draft I believe is necessary before publication.
>
> This draft was presented at IETF 117 last summer by Mohamed Boucadair
> and adopted on November 6th 2023.  As the draft was adopted fairly
> recently, my goal is to catch any issues with the draft before
> publication.
>
> The 3 additional drafts below were reviewed together as requested.
>
> ! Draft being reviewed
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
>
> ! Additional drafts reviewed
> draft-ietf-opsawg-ntw-attachment-circuit-05
> draft-ietf-opsawg-teas-attachment-circuit-06
> draft-ietf-opsawg-teas-common-ac-05
>
> All 4 drafts were adopted on November 6th 2023.
>
> I ran IDNITS against all 4 drafts and result was "no issues found
> here"
>
> Routing Area Directorate Review request Main Draft
> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
>
> Major Issues:
> None
>
> Minor Issues:
> The main use case for this draft is for network slicing

[Med] Actually, no. This draft focuses on binding LxVPN to ACs. The required 
functionality to bind a slice service with ACs is built as part of the service 
slice model itself. FWIW, draft-ietf-teas-ietf-network-slice-nbi-yang includes 
the following:

   *  "ac-svc-name": Indicates the names of AC services, for association
  purposes, to refer to the ACs that have been created.  When both
  "ac-svc-name" and the attributes of "attachment-circuits" are
  defined, the "ac-svc-name" takes precedence.

 | +--rw ac-svc-name*  string
 | +--rw attachment-circuits
 | |  +--rw attachment-circuit* [id]
     |     | +--rw id   string
 | | +--rw description? string
 | | +--rw ac-svc-name? string

 that is to be
> used as discussed in TEAS WG IETF 117 by author Mohamed Boucadair.  As
> that is the main use case I wonder if it makes sense to add that to
> the introduction.  RFC 8466 L2SM, RFC 8299 L3SM Service modules were
> published in 2018 and RFC 9291 L2NM, RFC 9182 L3NM were published in
> 2022.  So it has been pretty recent since the Network Modules have
> been published but not as recent for the Service modules.
> The idea and concept of an AC or AC Glue has not been developed until
> just this past November.  As Network slicing is the main use case for
> the glue model would it be possible to add Network slicing as the
> example in Appendix A.

[Med] We already have such example in 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-08#name-binding-attachment-circuits
 (Figure 40), where this makes

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-teas-attachment-circuit-10.txt

2024-04-11 Thread mohamed . boucadair

Hi all, 

As reported in IETF#119, we updated the spec with new examples to illustrate:
* the use of the model for interconnection/peering purposes
* how the model can be used in complex contexts with dynamic network functions 
in the clouds

We also made other checks to prepare the full AC I-Ds set to the WGLC. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : jeudi 11 avril 2024 09:13
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : I-D Action: draft-ietf-opsawg-teas-attachment-circuit-10.txt
> 
> 
> Internet-Draft draft-ietf-opsawg-teas-attachment-circuit-10.txt is now
> available. It is a work item of the Operations and Management Area
> Working Group (OPSAWG) WG of the IETF.
> 
>Title:   YANG Data Models for Bearers and 'Attachment Circuits'-as-
> a-Service (ACaaS)
>Authors: Mohamed Boucadair
> Richard Roberts
> Oscar Gonzalez de Dios
> Samier Barguil Giraldo
> Bo Wu
>Name:draft-ietf-opsawg-teas-attachment-circuit-10.txt
>Pages:   137
>Dates:   2024-04-11
> 
> Abstract:
> 
>This document specifies a YANG service data model for Attachment
>Circuits (ACs).  This model can be used for the provisioning of ACs
>before or during service provisioning (e.g., Network Slice
> Service).
>The document also specifies a service model for managing bearers
> over
>which ACs are established.
> 
>Also, the document specifies a set of reusable groupings.  Whether
>other service models reuse structures defined in the AC models or
>simply include an AC reference is a design choice of these service
>models.  Utilizing the AC service model to manage ACs over which a
>service is delivered has the advantage of decoupling service
>management from upgrading AC components to incorporate recent AC
>technologies or features.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-teas-attachment-
> circuit%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4a65c18e3ff
> c4670e8db08dc59f6dfe7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> 484164092644089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=l5EYueFkSAdDy%
> 2BuxGEHiW4Swd6msYyYN2iC5kGhoYcE%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-teas-attachment-circuit-
> 10.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4a65c18e3ffc46
> 70e8db08dc59f6dfe7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638484
> 164092656691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HtnaJ0tgmK3XnaK4C
> q5Me1WmrhStZ%2Bjf%2BB%2Bnwv%2B5zhk%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-teas-attachment-
> circuit-
> 10&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4a65c18e3ffc4670e8d
> b08dc59f6dfe7%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63848416409
> 2669135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KmY%2Fm7hF%2B70hfYiLRl
> 3rBJREu3WS5cptjiBtx37QSi8%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 


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] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

2024-04-11 Thread mohamed . boucadair

Hi all, 

This is really useful work. I support adoption. 

Some coordination with other WGs will be needed, but I'm confident 
Carlos/Adrian will drive that through.

I have comments about some of the proposed terms: consider path coupled/path 
decoupled OAM instead of path path-congruent terms + “User Data Embedded OAM” 
or “OAM-embedded User Data” instead of the ambiguous “in-packet OAM”. 

I trust that discussion to continue when (hopefully) the doc is adopted.

Thank you.

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de Henk Birkholz
> Envoyé : mercredi 10 avril 2024 13:06
> À : OPSAWG 
> Objet : [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-
> whaaat-question-mark-03
> 
> 
> Dear OPSAWG members,
> 
> this email starts a call for Working Group Adoption of
> 
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Farchive%2Fid%2Fdraft-pignataro-opsawg-oam-whaaat-
> question-m
> > ark-
> 03.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C443f572f51
> >
> af4bee4cbd08dc594e2f2f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> >
> 8483439534955276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WsZJskcEImRAO
> > mAS9feqGgSEAPV4R0Cz%2F5aPbpF1kOI%3D&reserved=0
> 
> ending on Thursday, May 2nd.
> 
> As a reminder, this I-D summarizes how the term "Operations,
> Administration, and Maintenance" (OAM) is used currently &
> historically in the IETF and intends to consolidate unambiguous and
> protocol agnostic terminology for OAM. The summary includes
> descriptions of narrower semantics introduced by added qualifications
> the term OAM and a list of common capabilities that can be found in
> nodes processing OAM packets.
> 
> The chairs acknowledge a positive poll result at IETF119, but there
> has not been much discussion on the list yet. We would like to gather
> feedback from the WG if there is interest to further contribute and
> review. As a potential enabler for discussions, this call will last
> three weeks.
> 
> Please reply with your support and especially any substantive comments
> you may have.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 


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] AD review of draft-ietf-opsawg-ipfix-fixes

2024-04-14 Thread mohamed . boucadair

Hi Mahesh,

Thank you for the review.

The candidate version to address your review can be seen at: Diff: 
draft-ietf-opsawg-ipfix-fixes.txt - 
draft-ietf-opsawg-ipfix-fixes.txt.

Please see inline for more context.

Cheers,
Med

De : Mahesh Jethanandani 
Envoyé : dimanche 14 avril 2024 05:21
À : draft-ietf-opsawg-ipfix-fi...@ietf.org
Cc : opsawg@ietf.org
Objet : AD review of draft-ietf-opsawg-ipfix-fixes


Hi Authors,

Thank you for working on this document, This is my review of 
draft-ietf-opsawg-ipfix-fixes-06 draft. They are roughly divided between 
COMMENT and NIT. The COMMENTs should be resolved before this document is sent 
for IETF LC for publication as a Draft Standard.

---
COMMENT
---

Section 1, paragraph 2
>When OPSAWG was considering [I-D.ietf-opsawg-rfc7125-update] which
>updates [RFC7125], the WG realized that some other parts of the IANA
>IP Flow Information Export (IPFIX) registry [IANA-IPFIX] were not up-
>to-date.  Indeed, since its initial creation in 2007, some IPFIX
>Information Elements (IEs) are no longer adequately specified (while
>they were at some point in time in the past).  This document intends
>to update the IANA registry and bring some consistency among the
>entries of the registry.


For a specification to "no longer adequately" specify an IE, the underlying 
specification for IPFIX must have changed. If that is so, can you cite what 
changed? If not, I would just remove the statement. It is not serving any 
purpose in this specification.

[Med] We used to have update to description text of other IEs but those were 
removed as the decision was to deprecate them. So, OK to remove this sentence 
as well.

Section 1, paragraph 1
>As discussed with IANA during the publication process of [RFC9487],
>the "Additional Information" entry in [IANA-IPFIX] should contain a
>link to an existing registry, when applicable, as opposed to having:


What happens to the existing registries? Does Section 6 take care of all of 
them? Should the link in existing registries not specified in Section 6, also 
move to Additional Information?

[Med] Modifications to existing entries are covered in this doc.

Section 3, paragraph 3

Since Sections 4-7 are really for the IANA Consideration section, why not move 
them there?

[Med] I prefer to leave them in the core document to record the OLD/NEW; not 
only the IANA actions. Thanks.

Section 4.1.2, paragraph 0
> - Description:  This Information Element describes the forwarding
> status of the flow and any attached reasons.
> IPFIX reduced-size encoding is used as required.


I know that you explain what reduced-size encoding in the other IPFIX 
documents, but it will be worth repeating it here or refer to that definition 
from here.

[Med] We do already provide the authoritative definition in the para right 
before:

==
The description is also updated to clarify the use of the reduced-size encoding 
as per Section 6.2 of 
[RFC7011].
==

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "he"; alternatives might be "they", "them", "their"

[Med] That one is correct as we refer to Andrew.

 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"

[Med] We can't do nothing here because that points to:

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
  Address Translator (Traditional NAT)", RFC 3022,
  DOI 10.17487/RFC3022, January 2001,
  https://www.rfc-editor.org/rfc/rfc3022.


---
NIT
---

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Uncited references: [RFC_Errata_1739] and [RFC_Errata_1738].

[Med] Fixed. Thanks.

Reference [RFC2482] to RFC2482, whi

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

2024-04-15 Thread mohamed . boucadair

Hi Mahesh,

Thank you for the review.

The changes can be tracked at: Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh.txt - 
draft-ietf-opsawg-ipfix-tcpo-v6eh.txt.

Please see more context inline.

Cheers,
Med

De : Mahesh Jethanandani 
Envoyé : dimanche 14 avril 2024 21:42
À : draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org
Cc : opsawg@ietf.org; pait...@ciena.com
Objet : AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi Authors,

Thanks for working on this document.

Here is my AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh-10 version of the 
draft. They are divided between COMMENT and NIT. I expect that the COMMENTs 
will be resolved before the document is sent to IETF Last Call.

---
COMMENT
---

Section 1, paragraph 1

Should the draft-ietf-opsawg-ipfix-fixes be referenced also?

[Med] We used to refer to that I-D till the WG decided to deprecate the IEs. No 
need to have that ref back.

How about reference to RFC 7012 which is only mentioned in the Security 
Considerations section?
[Med] That's OK as the authoritative reference for the IEs/data types is the 
IANA registry itself.

Section 1.1, paragraph 12
>Section 3 addresses these issues.  Also, ipv6ExtensionHeaders IPFIX
>IE is deprecated in favor of the new IEs defined in this document.

On the question of how a legacy client receiver receiving this new 
ipv6ExtensionHeader definition would react, I was wondering if a forward 
reference to the Operational Considerations be made. Otherwise, till one reads 
that section, it is not clear what a legacy client should do.

[Med] Not sure what you meant by "legacy client receiver", but I suspect you 
mean the collector. If that is what you had in mind, then usual rfc7011 applies 
for manipulating templates, etc.

Section 1.2, paragraph 3
>*  Describe how any observed TCP option in a Flow can be exported
>   using IPFIX.  Only TCP options having a kind <= 63 can be exported
>   in a tcpOptions IE.


Is the problem that no TCP options can be exported using IPFIX, or is that TCP 
options having a Kind value >= 64 cannot be exported? Note, the first sentence 
starts by saying "how any observed TCP option in a Flow can(not) be exported", 
the not added from the sentence above.

[Med] That's an issue because we don't have full visibility on the options 
present in flow. For example, TCP-ENO or shared option can't be reported with 
(deprecated) tcpOptions.


Section 1.2, paragraph 4
>Section 4 addresses these issues.  Also, tcpOptions IE is deprecated
>in favor of the new IEs defined in this document.

Same comment as above on providing a forward reference.

Section 3.3, paragraph 7
>Abstract Data Type:  unsigned256

I wonder why the opinion of a Expert Reviewer was overridden on the choice of 
defining this as unsigned256 instead of a bitfield.  I understand that there is 
precedence of using unsigned values for "flags", but as Paul noted, the value 
of a unsigned number is meaningless in the case where the individual bits hold 
values, not the whole unsigned number. Was it because of reduced-encoding?
[Med] The current design is consistent with how flags are handled in IPFIX. As 
you also rightfully mentioned, support of reduced-encoding is a key feature to 
support here given the long type. Please note that RFC7011 is explicit about 
target types:


   Reduced-size encoding MAY be applied to the following integer types:

   unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.

   The signed versus unsigned property of the reported value MUST be

   preserved.  The reduction in size can be to any number of octets

   smaller than the original type if the data value still fits, i.e., so

   that only leading zeroes are dropped.  For example, an unsigned64 can

   be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

As a side note, we discussed with Benoît whether we need we tag this I-D as 
formally updating RFC7011 but we finally preferred to no do so because the 
authoritative registry for the data type is the registry.

If so, that should be stated as the reason. BTW, can a bitfield not have 
similar semantics of reduced-encoding, if all the (MSB) bits are not being used?

[Med] There is no "bitfield" data type. The only mention of "bit field" in 7011 
is the following


   "flags" is an integral value that represents a set of bit fields.
   Logical operations are appropriate on such values, but other
   mathematical operations are not.  Flags MUST always be of an unsigned
   data type.

"bit field" is used for almost all IEs with flags (IP Flow Information Export 
(IPFIX) En

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-fixes

2024-04-15 Thread mohamed . boucadair

Hi Mahesh,

Thank you for the follow-up. Will proceed with the submission of the new 
version.

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani 
Envoyé : lundi 15 avril 2024 21:05
À : BOUCADAIR Mohamed INNOV/NET 
Cc : draft-ietf-opsawg-ipfix-fi...@ietf.org; opsawg@ietf.org
Objet : Re: AD review of draft-ietf-opsawg-ipfix-fixes

Hi Med,

Thanks for addressing most of the comments. One comment and one clarification.

This might be the iddiff tool, but in the diff file you shared I see the 
following under the title of the draft:

draft-ietf-opsawg-ipfix-fixes-latest

I was expecting to see a number, not the word latest.

[Med] That's normal. "latest" will be automatically bumped when the draft will 
be published.

For the clarification, see below with [mj].

On Apr 14, 2024, at 11:07 PM, 
mohamed.boucad...@orange.com wrote:

Hi Mahesh,

Thank you for the review.

The candidate version to address your review can be seen at: Diff: 
draft-ietf-opsawg-ipfix-fixes.txt - 
draft-ietf-opsawg-ipfix-fixes.txt.

Please see inline for more context.

Cheers,
Med

De : Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Envoyé : dimanche 14 avril 2024 05:21
À : 
draft-ietf-opsawg-ipfix-fi...@ietf.org
Cc : opsawg@ietf.org
Objet : AD review of draft-ietf-opsawg-ipfix-fixes

Hi Authors,

Thank you for working on this document, This is my review of 
draft-ietf-opsawg-ipfix-fixes-06 draft. They are roughly divided between 
COMMENT and NIT. The COMMENTs should be resolved before this document is sent 
for IETF LC for publication as a Draft Standard.

---
COMMENT
---

Section 1, paragraph 2
>When OPSAWG was considering [I-D.ietf-opsawg-rfc7125-update] which
>updates [RFC7125], the WG realized that some other parts of the IANA
>IP Flow Information Export (IPFIX) registry [IANA-IPFIX] were not up-
>to-date.  Indeed, since its initial creation in 2007, some IPFIX
>Information Elements (IEs) are no longer adequately specified (while
>they were at some point in time in the past).  This document intends
>to update the IANA registry and bring some consistency among the
>entries of the registry.

For a specification to "no longer adequately" specify an IE, the underlying 
specification for IPFIX must have changed. If that is so, can you cite what 
changed? If not, I would just remove the statement. It is not serving any 
purpose in this specification.

[Med] We used to have update to description text of other IEs but those were 
removed as the decision was to deprecate them. So, OK to remove this sentence 
as well.

Section 1, paragraph 1
>As discussed with IANA during the publication process of [RFC9487],
>the "Additional Information" entry in [IANA-IPFIX] should contain a
>link to an existing registry, when applicable, as opposed to having:

What happens to the existing registries? Does Section 6 take care of all of 
them? Should the link in existing registries not specified in Section 6, also 
move to Additional Information?

[Med] Modifications to existing entries are covered in this doc.

[mj] When you say existing entries, do you mean all existing entries currently 
in the IANA registry?

[Med] We are actually fixed all existing entries to be consistent with the text 
quoted in Section 1, par 1.

Section 3, paragraph 3

Since Sections 4-7 are really for the IANA Consideration section, why not move 
them there?

[Med] I prefer to leave them in the core document to record the OLD/NEW; not 
only the IANA actions. Thanks.

Section 4.1.2, paragraph 0
> - Description:  This Information Element describes the forwarding
> status of the flow and any attached reasons.
> IPFIX reduced-size encoding is used as required.

I know that you explain what reduced-size encoding in the other IPFIX 
documents, but it will be worth repeating it here or refer to that definition 
from here.

[Med] We do already provide the authoritative definition in the para right 
before:

==
The description is also updated to clarify the use of the reduced-size encoding 
as per Section 6.2 of 
[RFC7011].
==

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "he"; alternatives might be "they", "them", "their"

[Med] That one is correct as we r

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

2024-04-15 Thread mohamed . boucadair

Hi Mahesh,

Please see inline.

Cheers,
Med

Orange Restricted
De : Mahesh Jethanandani 
Envoyé : lundi 15 avril 2024 22:47
À : BOUCADAIR Mohamed INNOV/NET 
Cc : draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org; opsawg@ietf.org; 
pait...@ciena.com
Objet : Re: AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi Med,

Thanks for addressing most of the comments. Two follow-up comments. See below 
with [mj]

On Apr 15, 2024, at 4:51 AM, 
mohamed.boucad...@orange.com wrote:

Hi Mahesh,

Thank you for the review.

The changes can be tracked at: Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh.txt - 
draft-ietf-opsawg-ipfix-tcpo-v6eh.txt.

Please see more context inline.

Cheers,
Med

De : Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Envoyé : dimanche 14 avril 2024 21:42
À : 
draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org
Cc : opsawg@ietf.org; 
pait...@ciena.com
Objet : AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi Authors,

Thanks for working on this document.

Here is my AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh-10 version of the 
draft. They are divided between COMMENT and NIT. I expect that the COMMENTs 
will be resolved before the document is sent to IETF Last Call.

---
COMMENT
---

Section 1, paragraph 1

Should the draft-ietf-opsawg-ipfix-fixes be referenced also?

[Med] We used to refer to that I-D till the WG decided to deprecate the IEs. No 
need to have that ref back.

How about reference to RFC 7012 which is only mentioned in the Security 
Considerations section?
[Med] That's OK as the authoritative reference for the IEs/data types is the 
IANA registry itself.

Section 1.1, paragraph 12
>Section 3 addresses these issues.  Also, ipv6ExtensionHeaders IPFIX
>IE is deprecated in favor of the new IEs defined in this document.

On the question of how a legacy client receiver receiving this new 
ipv6ExtensionHeader definition would react, I was wondering if a forward 
reference to the Operational Considerations be made. Otherwise, till one reads 
that section, it is not clear what a legacy client should do.

[Med] Not sure what you meant by "legacy client receiver", but I suspect you 
mean the collector. If that is what you had in mind, then usual rfc7011 applies 
for manipulating templates, etc.

Section 1.2, paragraph 3
>*  Describe how any observed TCP option in a Flow can be exported
>   using IPFIX.  Only TCP options having a kind <= 63 can be exported
>   in a tcpOptions IE.

Is the problem that no TCP options can be exported using IPFIX, or is that TCP 
options having a Kind value >= 64 cannot be exported? Note, the first sentence 
starts by saying "how any observed TCP option in a Flow can(not) be exported", 
the not added from the sentence above.

[Med] That's an issue because we don't have full visibility on the options 
present in flow. For example, TCP-ENO or shared option can't be reported with 
(deprecated) tcpOptions.

[mj] În that case, do you want to:

s/Describe how any observed TCP options/Describe how some observed TCP options/

[Med] Works for me. Fixed. Thanks.

Section 1.2, paragraph 4
>Section 4 addresses these issues.  Also, tcpOptions IE is deprecated
>in favor of the new IEs defined in this document.

Same comment as above on providing a forward reference.

Section 3.3, paragraph 7
>Abstract Data Type:  unsigned256

I wonder why the opinion of a Expert Reviewer was overridden on the choice of 
defining this as unsigned256 instead of a bitfield.  I understand that there is 
precedence of using unsigned values for "flags", but as Paul noted, the value 
of a unsigned number is meaningless in the case where the individual bits hold 
values, not the whole unsigned number. Was it because of reduced-encoding?
[Med] The current design is consistent with how flags are handled in IPFIX. As 
you also rightfully mentioned, support of reduced-encoding is a key feature to 
support here given the long type. Please note that RFC7011 is explicit about 
target types:

   Reduced-size encoding MAY be applied to the following integer types:

   unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.

   The signed versus unsigned property of the reported value MUST be

   preserved.  The reduction in size can be to any number of octets

   smaller than the original type if the data value still fits, i.e., so

   that only leading zeroes are dropped.  For example, an unsigned64 can

   be reduced in size to 7, 6, 5, 4, 3,

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

Hi Greg, all,

Having this discussion is by its own sufficient to justify why we need to amend 
rfc6291 with terms that reflect recent needs/usages in a manner that can be 
easily and generally visible to the target audience.

For example, Michael indicated that he wished he had a better name for "Virtual 
In-Band OAM" (I still don’t digest what does that mean actually). I also 
indicated that I wished I had terms for the following when I edited RFC 9451:

  *   “OAM packet that exclusively includes OAM data”
  *   “OAM packet that includes user data”

I think that we can leverage some definition entries in various documents out 
there (detnet, for example) when this makes sense. Some of the existing terms, 
although used in RFCs, fail to unambiguously convey the intended meaning. I 
don’t think it is problematic to acknowledge that fact and consider alternate 
terms.

Of course, this is a cross-WG effort and a pre-requisite I expect for it is 
that the authors commit in soliciting the feedback from relevant WGs.

I don’t think it is premature to consider adopting this work here in OPSAWG. As 
you know, the content is not frozen given that this is simply a call for 
adoption, not a Last Call.

Cheers,
Med

De : OPSAWG  De la part de Greg Mirsky
Envoyé : mardi 16 avril 2024 10:11
À : Carlos Pignataro 
Cc : OPSAWG 
Objet : Re: [OPSAWG] 🔔 WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03

Dear Carlos,
thank you for making my point even clearer. I do believe that a term may have 
interpretation in different scopes - a document, a series of documents, or 
across all IETF documents. RFC 9551 established the interpretation of terms for 
all DetNet OAM documents. The document under discussion, 
draft-pignataro-opsawg-oam-whaaat-question-mark, as I understand its intention, 
is to establish the scope across all IETF documents. That, IMHO, imposes on the 
decision already made by the DetNet WG (and, AFAICS, shared by several other 
WGs). That is why I consider the WG AP premature and encourage the authors to 
reach out across the WG and Area boundaries to socialize the document more 
before taking any steps to progress it.

Regards,
Greg

On Tue, Apr 16, 2024 at 4:52 AM Carlos Pignataro 
mailto:cpign...@gmail.com>> wrote:
Greg,

Repeating something does not make it so…

You had argued that those were definitions only within the context of DetNet, 
and each context can have different ones. You really cannot have it both ways. 
This is confusing.

I-Ds follow causality — lots of things were approved to then be corrected.

In-band — out-of-band — what do they really mean when…

There is no “band”



C

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows


On Apr 15, 2024, at 09:03, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Hi Carlos,
I have to repeat that the definitions of terms "in-band OAM", "out-of-band 
OAM", and "on-path telemetry"
   In-band OAM:  an active OAM method that is in band within the
  monitored DetNet OAM domain when it traverses the same set of
  links and interfaces receiving the same QoS and Packet
  Replication, Elimination, and Ordering Functions (PREOF) treatment
  as the monitored DetNet flow.

   Out-of-band OAM:  an active OAM method whose path through the DetNet
  domain may not be topologically identical to the path of the
  monitored DetNet flow, its test packets may receive different QoS
  and/or PREOF treatment, or both.

   On-path telemetry:  on-path telemetry can be realized as a hybrid OAM
  method.  The origination of the telemetry information is
  inherently in band as packets in a DetNet flow are used as
  triggers.  Collection of the on-path telemetry information can be
  performed using in-band or out-of-band OAM methods.

have been adopted by DetNet WG, approved by IESG and published as part of RFC 
9551. I believe that a constructive 
approach would be to use the already accepted terminology, not to attempt to 
negate what has already been achieved in building up the IETF dictionary, 
particularly in the OAM area.

Regards,
Greg

On Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro 
mailto:cpign...@gmail.com>> wrote:
Dear Greg,

Thank you for the input.

It appears that much of what you write below was already discussed at 
https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/

Am I to understand you might be keen on continuing using "in-band OAM" with 
different meanings depending on the WG or context?

Please find some follow-ups inline below:

On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:
Dear All,
I've read the latest version of the draft, Please find my notes and questions 
below:

  *   All SDOs that standardize methods and/or protocols in the field of OAM 
recognize that, in the FCAPS network management model, OAM is addressing the 
'F' and 'P', i.e., Fault Management and Performance Moni

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

Re-,

I'm afraid so. 

I may see a construct where one would need to insist that "virtual out-of-band" 
is actually relying on an underlying (physical/shared) in-band thing. But, 
something which is in-band; no matter whether this is virtual or physical, it 
is still in-band.

Cheers,
Med

> -Message d'origine-
> De : Michael Richardson 
> Envoyé : mardi 16 avril 2024 15:20
> À : BOUCADAIR Mohamed INNOV/NET ; OPSAWG
> 
> Objet : Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-
> oam-whaaat-question-mark-03
> 
> 
> mohamed.boucad...@orange.com wrote:
> > For example, Michael indicated that he wished he had a better
> name for
> > "Virtual In-Band OAM" (I still don’t digest what does that mean
> > actually). I also indicated that I wished I had terms for the
> following
> > when I edited RFC 9451:
> 
> The fact that you don't know what it means from the term means that we
> got something wrong in the name in my opinion :-)
> 
> --
> Michael Richardson. o O ( IPv6 IøT
> consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

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 last call review of draft-ietf-opsawg-ipfix-fixes-07

Hi Martin, 

Thank you for the review.

Good point about the ranges. Updated the text as you can see at: 
https://github.com/boucadair/simple-ipfix-fixes/pull/10/files.

I double checked the registry and found that same issue should be fixed for 
other IEs: https://github.com/boucadair/simple-ipfix-fixes/pull/11/files. 
Please note that unlike the other entries, I'm not listing DCCP for 
collectorTransportPort/exporterTransportPort because of rfc7011#section-10.

Added a note for the IANA so that consistent referencing is used.

Cheers,
Med

> -Message d'origine-
> De : Martin Duke via Datatracker 
> Envoyé : mercredi 17 avril 2024 00:55
> À : tsv-...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-fixes@ietf.org; last-c...@ietf.org;
> opsawg@ietf.org
> Objet : Tsvart last call review of draft-ietf-opsawg-ipfix-fixes-07
> 
> 
> Reviewer: Martin Duke
> Review result: Ready with Nits
> 
> This document has been reviewed as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments
> were written primarily for the transport area directors, but are
> copied to the document's authors and WG to allow them to address any
> issues raised and also to the IETF discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider
> this review as part of the last-call comments they receive. Please
> always CC tsv-...@ietf.org if you reply to or forward this review.
> 
> This document does some housekeeping on the IPFIX Information Elements
> registry, to conform to a standard table format and fix other minor
> errors. There are no transport protocol implications.
> 
> The reference to the port registry is correct. It might be good for
> PortRangeStart and PortRangeEnd to clarify that the linked registry is
> not just for TCP, but also UDP, SCTP, and DCCP.
> 


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] AD review of draft-ietf-opsawg-tsvwg-udp-ipfix

Hi Mahesh,

Thank you for the review.

The candidate version can be seen at: Diff: 
draft-ietf-opsawg-tsvwg-udp-ipfix.txt - 
draft-ietf-opsawg-tsvwg-udp-ipfix.txt

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani 
Envoyé : mardi 16 avril 2024 18:48
À : draft-ietf-opsawg-tsvwg-udp-ip...@ietf.org
Cc : opsawg@ietf.org
Objet : AD review of draft-ietf-opsawg-tsvwg-udp-ipfix


Hi Authors,

Thank you for working on this document. And thanks to Tommy Pauly, and Joe 
Touch for providing their reviews.

Here is my review that is divided between COMMENTs and NITs. I expect the 
COMMENTs to be resolved before the document is sent for IETF Last Call.

---
COMMENT
---

Section 1, paragraph 1
>IP Flow Information Export (IPFIX) [RFC7011] is a protocol that is
>widely deployed in operators networks for traffic management
>purposes

Would it be fair to say, that IPFIX is used for traffic monitoring and not 
directly traffic management?
[Med] It is actually given that it covers many aspects of the so-called FCAPS 
management function (see for example rfc5472#section-2). I added "({{Section 2 
of !RFC6632}}) where it is cited as part of "Core Network Management 
Protocols"".

Section 2, paragraph 2
>This document uses the IPFIX-specific terminology (e.g., Flow)
>defined in Section 2 of [RFC7011].  As in [RFC7011], these IPFIX-
>specific terms have the first letter of a word capitalized.
>
>Also, this document uses the terms defined in Section 3 of
>[I-D.ietf-tsvwg-udp-options].

It would help to identify which terms are being used from each of the documents 
in this draft.
[Med] cited the main terms.

Also, is the rule that the IPFIX specific terms have the first letter 
captilized?
[Med] This is a convention for terms such as Flow, Template, etc.

What about udpOptions?
[Med] For IEs, the convention in rfc7012#section-2.3 apply, that is:

   o  Names of Information Elements MUST start with lowercase letters.

   o  Composed names MUST use capital letters for the first letter of
  each component (except for the first one).  All other letters are
  lowercase, even for acronyms.  Exceptions are made for acronyms
  containing a mixture of lowercase and capital letters, such as
  'IPv4' and 'IPv6'.  Examples are "sourceMacAddress" and
  "destinationIPv4Address".

[Med] Added this NEW: "The document adheres to the naming conventions for 
Information Elements per {{Section 2.3 of !RFC7012}}."

Section 5, paragraph 3
>Figure 2: An Example of udpOptions IE

Can the description be expaned to say "An Example of udpOptions with EOL and 
APC options?

[Med] Sure. Fixed.

Section 5, paragraph 10
>  udpSafeExperimentalOptionExID IE:
>
>  MSB  LSB
>   1   2   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |  0x9858   | 0xE2D4|
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  udpUnsafeExperimentalOptionExID IE:
>
>   1   2   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |  0xC3D9   | 0x9658|
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   Figure 3: Example of UDP Experimental option IEs


This example is not clear or confusing. The explanation above talked about SAFE 
and UNSAFE Experimental options. How is the range of 0-191 for SAFE or the 
range of 192-255 encoded in these values?
[Med] The shared option in the safe range is (EXP, Kind=127) while it is (UEXP, 
Kind=254) for the unsafe. When a shared SAFE option is observed, the ExIDs it 
carries are exported using udpSafeExperimentalOptionExID IE. The same happens 
for UEXP but with udpUnsafeExperimentalOptionExID IE. The presence of 
udpSafeExperimentalOptionExID or udpUnsafeExperimentalOptionExID is explicit 
about whether EXP or UEXP were observed. Both can be observed in the same Flow 
as exemplified in this Section.


Or if they are not, because they come part of the UDP options, then how about 
showing what the UDP options field looks like? In other words, can Example 2 
and Example 3 be combined to show a more complete example?
[Med] I tweaked the example to also describe how the udpOptio

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt

2024-04-17 Thread mohamed . boucadair

Hi Douglas, all,

Thank you for taking care of the comments. I managed to review the latest 
version. FWIW, the comments can be retrieved here:


  *   Pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-opsawg-tacacs-tls13-06-rev%20Med.pdf
  *   Doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-ietf-opsawg-tacacs-tls13-06-rev%20Med.doc

There are still some points to be fixed, but I think the document is getting 
stable more and more.

Cheers,
Med

De : OPSAWG  De la part de Douglas Gash (dcmgash)
Envoyé : mercredi 20 mars 2024 16:40
À : opsawg@ietf.org
Cc : John Heasley ; Andrej Ota 
Objet : Re: [OPSAWG] New Version Notification for 
draft-ietf-opsawg-tacacs-tls13-06.txt

Dear OPSAWG,

We have uploaded a new version of the doc, primarily to address as much as 
possible of the comprehensive review kindly submitted by Mohamed Boucadair. We 
thank Mohamed for the time and trouble taken to the review the doc so 
thoroughly. We will be happy to discuss further any omissions or new comments 
and rectify quickly.

And we will endeavour to respond ASAP to any other comments of any kind on the 
doc.

Many thanks,

Regards,

The Authors.

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Date: Wednesday, 20 March 2024 at 15:27
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, Andrej 
Ota mailto:and...@ota.si>>, John Heasley 
mailto:h...@shrubbery.net>>, Thorsten Dahm 
mailto:thorsten.d...@gmail.com>>
Subject: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt
A new version of Internet-Draft draft-ietf-opsawg-tacacs-tls13-06.txt has been
successfully submitted by Douglas C. Medway Gash and posted to the
IETF repository.

Name: draft-ietf-opsawg-tacacs-tls13
Revision: 06
Title:TACACS+ TLS 1.3
Date: 2024-03-20
Group:opsawg
Pages:15
URL:  https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/
HTML: https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-tls13
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-06

Abstract:

   The Terminal Access Controller Access-Control System Plus (TACACS+)
   Protocol [RFC8907] 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 and obsoletes former inferior security
   mechanisms.



The IETF Secretariat

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] IPR POLL: Attachment circuits work

2024-04-19 Thread mohamed . boucadair

Hi Joe, all,

No, I'm not aware of any IPR that applies to these drafts.

Cheers,
Med

De : OPSAWG  De la part de Joe Clarke (jclarke)
Envoyé : vendredi 19 avril 2024 16:32
À : opsawg@ietf.org
Objet : [OPSAWG] IPR POLL: Attachment circuits work

We're up to WG LC on these four drafts.  And while we did an IPR poll before, 
we want to be thorough since this work has evolved.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

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 these drafts"
or
"Yes, I'm aware of IPR that applies to these drafts"

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.

Also please send the response to the list above, and not unicast it.

As of this time, no IPR has been disclosed on any of the four drafts.

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 
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 Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt.

2024-04-19 Thread mohamed . boucadair

Hi Douglas,

Please see inline.

Cheers,
Med

De : Douglas Gash (dcmgash) 
Envoyé : vendredi 19 avril 2024 18:46
À : BOUCADAIR Mohamed INNOV/NET 
Cc : John Heasley ; Andrej Ota ; Thorsten 
Dahm ; opsawg@ietf.org
Objet : Re: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt.


Hi Mohamad,

We are working through the comments and enhancements that you kindly sent.

There are two comments that we'd be grateful if you could clarify:


  1.  BMI10: "What about raw public keys?" (on: Implementations MAY support TLS 
authentication with Pre-Shared Keys): I'm guessing this relates to fact that, 
as we mention only PSK, that this indicates that we mean to imply that non PSK 
authentications are not included. If this is the case, then for sure, we will 
clarify that they are. If you have something else in mind, please expand, 
thanks!
[Med] Yeah.


  1.  BMI16: "What about configuration of name/address/port number of the 
server?" (on: Certificate Provisioning is out of scope of this document.), 
would be grateful if you could please expand on what you had in mind here
[Med] Clients should be provided with the IP address(es) and alternate port 
number (if the default is not used) of the server. Clients may also require to 
be provided with the domain name of the server. Also, given that you define 
"tacacss", do you had in mind to use that for service discovery?

Please note that if a name is also provided to the client, then you may 
indicate that the name will be used also for rfc9525 validation to compare the 
domain name with the certificate that is provided. If no name is provided, do 
you assume that the certificate is

BTW, I wonder whether you need to indicate whether the certificate authority 
that issued the server certificate will need to support at least DNS-ID and 
SRV-ID identifier types? I don't think URI-ID is needed. Similarly, do we need 
to include a mention about wildcard "*"? I think it SHOULD NOT.

Feel free to grab whatever useful for you. Thanks.

Many thanks!

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
mailto:mohamed.boucad...@orange.com>>
Date: Wednesday, 17 April 2024 at 16:42
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Cc: John Heasley mailto:h...@shrubbery.net>>, Andrej Ota 
mailto:and...@ota.si>>
Subject: RE: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt
Hi Douglas, all,

Thank you for taking care of the comments. I managed to review the latest 
version. FWIW, the comments can be retrieved here:


· Pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-opsawg-tacacs-tls13-06-rev%20Med.pdf

· Doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-ietf-opsawg-tacacs-tls13-06-rev%20Med.doc

There are still some points to be fixed, but I think the document is getting 
stable more and more.

Cheers,
Med

De : OPSAWG mailto:opsawg-boun...@ietf.org>> De la 
part de Douglas Gash (dcmgash)
Envoyé : mercredi 20 mars 2024 16:40
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : John Heasley mailto:h...@shrubbery.net>>; Andrej Ota 
mailto:and...@ota.si>>
Objet : Re: [OPSAWG] New Version Notification for 
draft-ietf-opsawg-tacacs-tls13-06.txt

Dear OPSAWG,

We have uploaded a new version of the doc, primarily to address as much as 
possible of the comprehensive review kindly submitted by Mohamed Boucadair. We 
thank Mohamed for the time and trouble taken to the review the doc so 
thoroughly. We will be happy to discuss further any omissions or new comments 
and rectify quickly.

And we will endeavour to respond ASAP to any other comments of any kind on the 
doc.

Many thanks,

Regards,

The Authors.

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Date: Wednesday, 20 March 2024 at 15:27
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, Andrej 
Ota mailto:and...@ota.si>>, John Heasley 
mailto:h...@shrubbery.net>>, Thorsten Dahm 
mailto:thorsten.d...@gmail.com>>
Subject: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt
A new version of Internet-Draft draft-ietf-opsawg-tacacs-tls13-06.txt has been
successfully submitted by Douglas C. Medway Gash and posted to the
IETF repository.

Name: draft-ietf-opsawg-tacacs-tls13
Revision: 06
Title:TACACS+ TLS 1.3
Date: 2024-03-20
Group:opsawg
Pages:15
URL:  https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/
HTML: https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-taca

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt.

2024-04-22 Thread mohamed . boucadair

ard "*"? I think it SHOULD NOT.
Agreed, I think there was a discussion on that, and it was discounted. 
We'll make that explicit
[Med] Thank you.

Feel free to grab whatever useful for you. Thanks.

Many thanks!

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
mailto:mohamed.boucad...@orange.com>>
Date: Wednesday, 17 April 2024 at 16:42
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Cc: John Heasley mailto:h...@shrubbery.net>>, Andrej Ota 
mailto:and...@ota.si>>
Subject: RE: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt
Hi Douglas, all,

Thank you for taking care of the comments. I managed to review the latest 
version. FWIW, the comments can be retrieved here:


Pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-opsawg-tacacs-tls13-06-rev%20Med.pdf

Doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-ietf-opsawg-tacacs-tls13-06-rev%20Med.doc

There are still some points to be fixed, but I think the document is getting 
stable more and more.

Cheers,
Med

De : OPSAWG mailto:opsawg-boun...@ietf.org>> De la 
part de Douglas Gash (dcmgash)
Envoyé : mercredi 20 mars 2024 16:40
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : John Heasley mailto:h...@shrubbery.net>>; Andrej Ota 
mailto:and...@ota.si>>
Objet : Re: [OPSAWG] New Version Notification for 
draft-ietf-opsawg-tacacs-tls13-06.txt

Dear OPSAWG,

We have uploaded a new version of the doc, primarily to address as much as 
possible of the comprehensive review kindly submitted by Mohamed Boucadair. We 
thank Mohamed for the time and trouble taken to the review the doc so 
thoroughly. We will be happy to discuss further any omissions or new comments 
and rectify quickly.

And we will endeavour to respond ASAP to any other comments of any kind on the 
doc.

Many thanks,

Regards,

The Authors.

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Date: Wednesday, 20 March 2024 at 15:27
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, Andrej 
Ota mailto:and...@ota.si>>, John Heasley 
mailto:h...@shrubbery.net>>, Thorsten Dahm 
mailto:thorsten.d...@gmail.com>>
Subject: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt
A new version of Internet-Draft draft-ietf-opsawg-tacacs-tls13-06.txt has been
successfully submitted by Douglas C. Medway Gash and posted to the
IETF repository.

Name: draft-ietf-opsawg-tacacs-tls13
Revision: 06
Title:TACACS+ TLS 1.3
Date: 2024-03-20
Group:opsawg
Pages:15
URL:  https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/
HTML: https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-tls13
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-06

Abstract:

   The Terminal Access Controller Access-Control System Plus (TACACS+)
   Protocol [RFC8907] 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 and obsoletes former inferior security
   mechanisms.



The IETF Secretariat



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.



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

Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-05.txt

2024-04-22 Thread mohamed . boucadair

Hi all,

Like Michael, I'm puzzled about the development of this draft. 

I raised comments back in 05/2021 that I reiterated during the call for 
adoption: 
https://mailarchive.ietf.org/arch/msg/opsawg/OlkjFOk55hB-29UG4FQaNbunXTY/ but 
still see the same issues in 2024. Putting aside the list/leaf-list thing, the 
other points are straightforward such as fixing a json example.

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de Eliot Lear
> Envoyé : lundi 22 avril 2024 20:02
> À : Michael Richardson ; opsawg@ietf.org;
> m...@ietf.org
> Objet : Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-
> 05.txt
> 
 
> On 22.04.2024 19:29, Michael Richardson wrote:
> > 0) Why is this document still kicking around the WG?
> > (Too bad it doesn't have the word "mud" in the filename.)
> >
> > 1) I find the title confusing.
> >
> > 2) I don't think that AUGMENT does what you want, because YANG
> is not
> > extensible in the way we are used to doing with IANA.
> >
> > 3) I think that you have to revise the MUD specification
> itself.
> >
> > internet-dra...@ietf.org wrote:
> >  > Internet-Draft draft-ietf-opsawg-ol-05.txt is now
> available. It is a work item
> >  > of the Operations and Management Area Working Group
> (OPSAWG) WG of the IETF.
> >
> >  > Title:   Ownership and licensing statements in YANG
> >  > Authors: Eliot Lear
> >  > Carsten Bormann
> >  > Name:draft-ietf-opsawg-ol-05.txt
> >  > Pages:   8
> >  > Dates:   2024-04-18
> >
> >  > Abstract:
> >
> >  > This memo provides for an extension to RFC 8520 that
> allows MUD file
> >  > authors to specify ownership and licensing of MUD files
> themselves.
> >  > This memo updates RFC 8520.  However, it can also be
> used for
> >  > purposes outside of MUD, and the grouping is structured
> as such.
> >
> >  > The IETF datatracker status page for this Internet-Draft
> is:
> >  >
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdata
> > tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-
> ol%2F&data=05%7C02%7Cmohame
> >
> d.boucadair%40orange.com%7C92093d31adb04e54433408dc62f660b8%7C90c
> 7a20a
> >
> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638494057558027066%7CUnknown%7
> CTWFp
> >
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn
> >
> 0%3D%7C0%7C%7C%7C&sdata=evbyUZ0QB67LVPRNDJMok1EDqirGGX3LRl5lcZBXY
> %2FA%
> > 3D&reserved=0
> >
> >  > There is also an HTML version available at:
> >  >
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.
> > ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ol-
> 05.html&data=05%7C02%7C
> >
> mohamed.boucadair%40orange.com%7C92093d31adb04e54433408dc62f660b8
> %7C90
> >
> c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638494057558035784%7CUnk
> nown%
> >
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJX
> >
> VCI6Mn0%3D%7C0%7C%7C%7C&sdata=ALyUu59W4HpqkNgltW2MR3tMIP0Oy7g2lx0
> eMO2B
> > WFw%3D&reserved=0
> >
> >  > A diff from the previous version is available at:
> >  >
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauth
> > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-ol-
> 05&data=05%7C
> >
> 02%7Cmohamed.boucadair%40orange.com%7C92093d31adb04e54433408dc62f
> 660b8
> >
> %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638494057558042269%
> 7CUnk
> >
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWw
> >
> iLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AuV0M7yp48hbdOAfzjyMxgo8hTJruD
> g7ijp
> > dwVJhrCY%3D&reserved=0
> >
> >  > Internet-Drafts are also available by rsync at:
> >  > rsync.ietf.org::internet-drafts
> >
> >
> >  > ___
> >  > OPSAWG mailing list
> >  > OPSAWG@ietf.org
> >  >
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=05%7C02%7Cmohamed.bou
> cadai
> >
> r%40orange.com%7C92093d31adb04e54433408dc62f660b8%7C90c7a20af34b4
> 0bfbc
> >
> 48b9253b6f5d20%7C0%7C0%7C638494057558048845%7CUnknown%7CTWFpbGZsb
> 3d8ey
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C0%7
> >
> C%7C%7C&sdata=dMV04fnfSh7yh8zTnekcIFHOpK5FAVqp8aKEMh0U8bQ%3D&rese
> rved=
> > 0
> >
> >
> > --
> > Michael Richardson. o O ( IPv6 IøT
> consulting )
> > Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >
> >
> >
> >

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

Re: [OPSAWG] Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13

2024-04-23 Thread mohamed . boucadair

Hi Doug,

Thank you for the updates. Looks good to me.

Noted the pending point about 9525, though.

One minor comment about the description in Section 7, I suggest to update 
"Description: Login Host Protocol (TACACSS)" to mention TLS or "secure" in the 
description to differentiate the new entry vs. the following existing ones:

==
tacacs 49   tcp  Login Host Protocol (TACACS)[Pieter_Ditmars] 
[Pieter_Ditmars]
tacacs 49   udp  Login Host Protocol (TACACS)[Pieter_Ditmars] 
[Pieter_Ditmars]
==

Cheers,
Med

De : Douglas Gash (dcmgash) 
Envoyé : mardi 23 avril 2024 15:54
À : opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET 
Cc : Andrej Ota ; John Heasley ; Thorsten 
Dahm 
Objet : Re: Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13


Dear OPSAWG, Mohamed,

This attest revision intends to address the majority of the issues raised in 
the last round of review (Thanks to Med)


There is one known outstanding issue at this time, to update the TLS 
Identification with reference to RFC 9525. We plan to include that, and 
revisions related to this draft version, shortly.

Many thanks.

The Authors.

From: IETF I-D Submission Tool 
mailto:idsubmiss...@ietf.org>>
Date: Tuesday, 23 April 2024 at 14:46
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
Andrej Ota mailto:and...@ota.si>>, John Heasley 
mailto:h...@shrubbery.net>>, Thorsten Dahm 
mailto:thorsten.d...@gmail.com>>
Subject: Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13

Hi,

The IETF datatracker Internet-Draft submission service has received your 
Internet-Draft
draft-ietf-opsawg-tacacs-tls13-07, and requires a
confirmation step in order to be able to complete the posting of
the Internet-Draft.
Please follow this link to the page where you can confirm the posting:

https://datatracker.ietf.org/submit/status/142126/confirm/9c5e13a4722a901ff95632148619611b/


Best regards,

The IETF Secretariat
through the Internet-Draft submission service


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] Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13

2024-04-23 Thread mohamed . boucadair

Re-,

This can wait unless the Chairs are planning to apply for an early port/service 
request SOON.

Cheers,
Med



Orange Restricted

De : Douglas Gash (dcmgash) 
Envoyé : mardi 23 avril 2024 17:16
À : BOUCADAIR Mohamed INNOV/NET ; opsawg@ietf.org
Cc : Andrej Ota ; John Heasley ; Thorsten 
Dahm 
Objet : Re: Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13

Will do. Would it be beneficial to enact an immediate new version upload for 
this?

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, 23 April 2024 at 16:05
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Cc: Andrej Ota mailto:and...@ota.si>>, John Heasley 
mailto:h...@shrubbery.net>>, Thorsten Dahm 
mailto:thorsten.d...@gmail.com>>
Subject: RE: Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13
Hi Doug,

Thank you for the updates. Looks good to me.

Noted the pending point about 9525, though.

One minor comment about the description in Section 7, I suggest to update 
"Description: Login Host Protocol (TACACSS)" to mention TLS or "secure" in the 
description to differentiate the new entry vs. the following existing ones:

==
tacacs 49   tcp  Login Host Protocol (TACACS)[Pieter_Ditmars] 
[Pieter_Ditmars]
tacacs 49   udp  Login Host Protocol (TACACS)[Pieter_Ditmars] 
[Pieter_Ditmars]
==

Cheers,
Med

De : Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>
Envoyé : mardi 23 avril 2024 15:54
À : opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : Andrej Ota mailto:and...@ota.si>>; John Heasley 
mailto:h...@shrubbery.net>>; Thorsten Dahm 
mailto:thorsten.d...@gmail.com>>
Objet : Re: Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13


Dear OPSAWG, Mohamed,

This attest revision intends to address the majority of the issues raised in 
the last round of review (Thanks to Med)


There is one known outstanding issue at this time, to update the TLS 
Identification with reference to RFC 9525. We plan to include that, and 
revisions related to this draft version, shortly.

Many thanks.

The Authors.

From: IETF I-D Submission Tool 
mailto:idsubmiss...@ietf.org>>
Date: Tuesday, 23 April 2024 at 14:46
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
Andrej Ota mailto:and...@ota.si>>, John Heasley 
mailto:h...@shrubbery.net>>, Thorsten Dahm 
mailto:thorsten.d...@gmail.com>>
Subject: Confirm submission of I-D draft-ietf-opsawg-tacacs-tls13

Hi,

The IETF datatracker Internet-Draft submission service has received your 
Internet-Draft
draft-ietf-opsawg-tacacs-tls13-07, and requires a
confirmation step in order to be able to complete the posting of
the Internet-Draft.
Please follow this link to the page where you can confirm the posting:

https://datatracker.ietf.org/submit/status/142126/confirm/9c5e13a4722a901ff95632148619611b/


Best regards,

The IETF Secretariat
through the Internet-Draft submission service



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.
Orange Restricted



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

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

2024-04-23 Thread mohamed . boucadair

Hi Alan, 

Please see one comment inline. 

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de Alan DeKok
> Envoyé : mardi 23 avril 2024 17:20
> À : opsawg 
> Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-
> 07.txt
> 
> 
>   Some comments on the latest draft:
> 
> 2.1. Obfuscation
> 
>   ... The algorithm is categorized as Obfuscation in Section
> 10.5.2 of [RFC8907]. The term should be interpreted to mean
> "plaintext"
> 
>   I wouldn't call it "plaintext", as it's not.  Perhaps instead
> just drop the "interpreted to mean plaintext" portion.
> 
> 2.2
> 
>   ... using unsecure TACACS+ authentication and obfuscation
> 
>   "insecure" instead of "unsecure".
> 
> 
> 3.1
> 
>   ... All data exchanged by TACACS+ peers MUST be encrypted,
> 
> Perhaps explicitly say that TLS cipher suites with NULL
> encryption are banned.  This is a little more quantitative.
> 
>   ... they will be deployed on different ports. Due to the
> widespread use of default port number settings in numerous
> existing TACACS+ client configurations, a well-known system
> TCP/IP port number will be requested from IANA.
> 
>   Perhaps just say "uses port TBD", and leave the IANA
> instructions in a separate IANA section.
> 
>   i.e. the final RFC doesn't need to contain text on "port will
> be requested from IANA"
> 
> 3.2
> 
>   ... Why it closed has no bearing on TLS resumption, unless
> closed by a TLS error, in which case the ticket might be
> invalidated.
> 
>   "might" seems wrong here.  If there is a TLS error, the server
> generally should discard any session tickets.  While RFC 8446
> doesn't say this, I'm not clear if there are any use-cases for
> resuming sessions which (for example) had previously failed with
> fatal TLS errors.
> 
> 3.2.2.
> 
>Are there any considerations for which CA to use, or what kind
> of CA to use?
> 
> 4
> 
>   [RFC8907] describes the obfuscation mechanism, documented in
> Section 5.2 of [RFC5425].
> 
>   The reference to 5425 seems wrong.
> 
> 5.1.1.1
> 
>   ... Non-TLS connections should not be used for new TACACS+
> deployments.
> 
>   Maybe SHOULD NOT?
> 
>   ... It is NOT RECOMMENDED to deploy TACACS+ wi
> 
>   I think this should be a MUST NOT
> 

[Med] I don't think the normative language is justified here as it will be 
redundant with this part:

   It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication
   and encryption, including TLS using the NULL algorithm, except for
   within test and debug environments.  

NOT RECOMMENDED is right as there is a clear exception called out.



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] advancing PCAP drafts

2024-04-25 Thread mohamed . boucadair

Hi Michael,

Any update about this draft? 

Other than fixing a bug in Table 3.1, I thought that we were close to the WGLC.

However, I checked 
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-pcaplinktype&url_2=https://IETF-OPSAWG-WG.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.txt
 and I'm afraid that your main copy override many changes agreed in the past. 
May be I'm not looking in the right branch?

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : lundi 5 février 2024 16:38
> À : 'Michael Richardson' ; opsawg@ietf.org
> Objet : RE: [OPSAWG] advancing PCAP drafts
> 
> Hi Michael,
> 
> Thanks for the follow-up.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Michael Richardson  Envoyé :
> mercredi 31
> > janvier 2024 15:10 À : BOUCADAIR Mohamed INNOV/NET
> > ; opsawg@ietf.org Objet : Re:
> [OPSAWG]
> > advancing PCAP drafts
> >
> >
> > mohamed.boucad...@orange.com wrote:
> > > Hmm...I remember at least the following candidates
> changes from
> > that
> > > thread, e.g.,
> >
> > > *
> > >
> >
> https://mailarchive.ietf.org/arch/msg/opsawg/u0__66zIpCMHA4syzt8f
> Wtyx9
> > 8Y/
> > > *
> > >
> >
> https://mailarchive.ietf.org/arch/msg/opsawg/ExlyBZ9eRP_UHUvCAmtK
> u0b28
> > Z4/
> >
> > > I trust that you will check that thread and do the right
> thing.
> > Thanks.
> >
> > I've been through that thread.
> > I think that I've got it all.
> > Please check the diff to -02.
> 
> [Med] Thanks. I like the new changes. Please note that there is a
> bug with the table in 3.1.
> 
> >
> > I don't know if ISE documents can create registries: one ISE
> told me
> > no.
> > The document is in the WG, so let's not religitate that now.
> 
> [Med] hmm, I was not reviving that ISE discussion :-( I was
> actually pointing to specific messages with some candidate
> changes (e.g. tag deprecated entries), which you adequately
> addressed in -02. Thanks.
> 
> >
> > > I sent you right now a PR with some minor edits.
> >
> > I believe that it was https://github.com/IETF-OPSAWG-WG/draft-
> ietf-
> > opsawg-pcap/pull/134
> > and it was merged nov 9.
> >
> > > For the specification required range, you may consider adding
> some
> > guidance for DEs.
> >
> > Done.  You may wish to read the diff, and maybe disagree with
> my
> > advice.
> >
> > > The initial table does not mirror the current values in
> > > https://www.tcpdump.org/linktypes.html. Also, some
> descriptions in
> > the
> > > table does not match exactly what is in that table. Not sure
> if it
> > is
> > > worth explaining the diff.
> >
> > I've updated the table with numbers out to 301.
> > I'm not sure about putting URLs in.
> >
> > > You may indicate that the procedure for assigning new codes
> as
> > > detailed in https://www.tcpdump.org/linktypes.html won't be
> followed
> > anymore.
> >
> > That's been updated in git, and may take a bit to go live.
> >
> > > Some assigned types seem to be used for private use while
> these
> > types
> > > fall now under a specification required range. I don't know
> if it is
> > > worth to have some consistency here and consider a range for
> future
> > > specification required type, e.g., 300-32767 that won't be
> mixed
> > with the historic ones.
> >
> > It's grandfathered as far as I'm concerned.

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] advancing PCAP drafts

2024-04-25 Thread mohamed . boucadair

Hi Guy, 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Guy Harris 
> Envoyé : jeudi 25 avril 2024 09:53
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Michael Richardson ; opsawg@ietf.org
> Objet : Re: [OPSAWG] advancing PCAP drafts
> 
> 
> On Apr 25, 2024, at 12:04 AM, mohamed.boucad...@orange.com wrote:
> 
> > Other than fixing a bug in Table 3.1, I thought that we were
> close to the WGLC.
> >
> > However, I checked
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fapi%2Fiddiff%3Fdoc_1%3Ddraft-ietf-
> opsawg-pcaplinktype%26url_2%3Dhttps%3A%2F%2FIETF-OPSAWG-
> WG.github.io%2Fdraft-ietf-opsawg-pcap%2Fdraft-ietf-opsawg-
> pcaplinktype.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C
> 13c4bd5b00e54c70a86608dc64fcbccd%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C638496283902976995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
> 7C%7C&sdata=63vT7d%2BgXfR5uGXyx4IzrF17HtVtE32lVY88KK2B2uQ%3D&rese
> rved=0 and I'm afraid that your main copy override many changes
> agreed in the past. May be I'm not looking in the right branch?
> 
> The changes I see from that link are:
> 
>   1) an unreadable table becomes readable, which is presumably
> what "fixing a bug in Table 3.1" refers to (although that's Table
> 1 in *Section* 3.1);
> 

[Med] The formatting is better, but the content isn't! For example, there were 
many entries that was agreed to tag them as deprecated but that tagging is now 
lost.


>   2) removal of the "Guidance for Designated Experts" section;
> 

[Med] ACK. This one should be reinserted back per a discussion we had in the 
past.

>   3) replacement of the "Contributors" section with "Insert
> pcap developers etc. here";
> 
>   4) replacement of the "Acknowledgments" section with "The
> authors wish to thank (many reviewers) and many others for their
> invaluable comments.".
> 
> In the Git repository for the pcaplinktypes, pcap, and pcapng
> drafts, the initial commit for draft-ietf-opsawg-pcaplinktype.md
> is
> 
>   commit 94d418970231e887ae24c233f4fc58862abe15d0
>   Author: Michael Richardson 
>   Date:   Fri Jul 29 17:01:43 2022 -0400
> 
>   create new document pcaplinktype, reference it
> 
> and that has the "fill in this field" versions of "Contributors"
> and "Acknowledgments".  All subsequent commits have messages that
> indicate minor changes.
> 
> Michael, what was the source from which the current I-D at
> 
>   https://eur03.safelinks.protection.outlook.com/?url=https%3A
> %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg-
> pcaplinktype&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C13c4
> bd5b00e54c70a86608dc64fcbccd%7C90c7a20af34b40bfbc48b9253b6f5d20%7
> C0%7C0%7C638496283902986361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7
> C&sdata=PLdjoCp7ZbyGjLBmRrjURWVVpPKW5GN0jaLcIfcZyWk%3D&reserved=0
> 
> was generated, and should the "Guidance for Designated Experts",
> "Contributors", and "Acknowledgments" sections be copied from
> that version to the current version in the repository?

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] Intdir last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11

2024-04-25 Thread mohamed . boucadair

Hi Dirk, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Dirk Von Hugo via Datatracker 
> Envoyé : jeudi 25 avril 2024 17:05
> À : int-...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Intdir last call review of draft-ietf-opsawg-ipfix-tcpo-
> v6eh-11
> 
> 
> Reviewer: Dirk Von Hugo
> Review result: Ready
> 
> Dear authors, intarea community,
> as assigned INT directorate reviewer for draft-ietf-opsawg-ipfix-
> tcpo-v6eh my comments were written primarily for the benefit of
> the Internet Area Directors.
> Document editors and shepherd(s) should treat these comments just
> like they would treat comments from any other IETF contributors
> and resolve them along with any other Last Call comments that
> have been received. For more details on the INT Directorate, see
>  2Fdatatracker.ietf.org%2Fgroup%2Fintdir%2Fabout%2F&data=05%7C02%7
> Cmohamed.boucadair%40orange.com%7C69088306607a4d9da34a08dc6539177
> b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638496543080533917
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EV%2BJhw3oV1e1uAlwz
> Of4Jm%2FT%2Fatkbc91nf2rOKcbB3k%3D&reserved=0>.
> 
> Based on my review, if I was on the IESG I would ballot this
> document as YES.
> 
> The content of vers. 11 has improved  and the additional IE
> specifications as well the data type specification seem to me
> useful and reasonable. I couldn't detect any minor nits.
> 
> Regarding sect. 8.4 I am not sure whether the term 'mirror'
> shouldn't be replaced by 'correspond' since only the protocol
> numbers are represented by identical values while 'Label' and
> 'Keyword' sometimes differ in this document and [IANA-Protocol]?

[Med] I think the OLD is correct, especially that we provides how the mirroring 
is done.

> So I would suggest to say: The "Label" corresponds to the
> "keyword" of an EH as indicated in [IANA-Protocols], while the
> "Protocol Number" mirrors the "Protocol Number" in [IANA-EH] and
> [IANA-Protocols].
> 
> In addition I would like to clarify whether the term 'otherwise'
> in sect. 8.4 means 'in all other cases when not a new code is
> assigned to an IPv6 EH in [IANA-EH] but an existing code in the
> registry is proposed to be modified'?

[Med] All other cases not allowed by mirroring. The nominal mode won't involve 
a DE because mirroring will be sufficient to reflect (new, modification, 
deprecate, etc.). "otherwise" is a catchup to cover cases where modifications 
are local to the registry, not the parent one. For example, we do have two 
entries for fragments, while only one protocol number is used for fragments in 
the parent EH registry. Thanks.

> 
> Thanks a lot and best regards
> Dirk
> 


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] advancing PCAP drafts

Hi Michael,

Thank you for fixing this.

FWIW, I created a PR that you can see at: 
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/pull/154/files. Please 
grab whatever you think useful out there.

I think that it would be useful to have a new column to easily tag the status 
of an assignment. Deprecated ones can be marked as such using that new column, 
instead of having this in the description. 

For the DE guidance, I'm afraid that the first part of your text is redundant 
with what is already in 8126, especially this part:

   For the Specification Required policy, review and approval by a
   designated expert (see Section 5) is required, and the values and
   their meanings must be documented in a permanent and readily
   available public specification, in sufficient detail so that
   interoperability between independent implementations is possible.

I think that you can reuse most of the text at: 
https://datatracker.ietf.org/doc/html/rfc9445#name-guidelines-for-the-designat

Cheers,
Med

> -Message d'origine-
> De : Michael Richardson 
> Envoyé : vendredi 26 avril 2024 21:14
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : opsawg@ietf.org
> Objet : Re: [OPSAWG] advancing PCAP drafts
> 
> 
> mohamed.boucad...@orange.com wrote:
> > However, I checked
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fapi%2Fiddiff%3Fdoc_1%3Ddraft-ietf-
> opsawg-pcaplinktype%26url_2%3Dhttps%3A%2F%2FIETF-OPSAWG-
> WG.github.io%2Fdraft-ietf-opsawg-pcap%2Fdraft-ietf-opsawg-
> pcaplinktype.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C
> 26eac497038c49be9e0d08dc66250bb2%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C638497556498067781%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
> 7C%7C&sdata=vvCk3DYritUqEttLZS%2BjnOXfYF2p7eqjPFHjzmcvYT0%3D&rese
> rved=0
> > and I'm afraid that your main copy override many changes
> agreed in the
> > past. May be I'm not looking in the right branch?
> 
> There is definitely a failure on my part to git push after the
> last posting.
> Guy then patched somethings, and I've just dealt with the
> conflict.
> Trailing periods on a bunch of entries.
> type 209, name changed.
> Some line wrapping changes too.
> 
> The table got broken in -02, sorry about that.
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fapi%2Fiddiff%3Fdoc_1%3Ddraft-ietf-
> opsawg-pcaplinktype-01%26url_2%3Dhttps%253A%252F%252FIETF-OPSAWG-
> WG.github.io%252Fdraft-ietf-opsawg-pcap%252Fdraft-ietf-opsawg-
> pcaplinktype.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C
> 26eac497038c49be9e0d08dc66250bb2%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C638497556498078518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
> 7C%7C&sdata=KGLwhQ%2FjVG31N2RAY0sXpgRhRTSKRhEq8rg9jKPmb4Y%3D&rese
> rved=0
> 
> might be a better diff.  I will post -03 now.
> 
> Let me paste in here the Designated Expert advice.
> What do you think about sentence two?  We aren't telling them not
> to accept specifications that are hard to get at, but rather to
> maybe push a bit for something more accessible.
> 
> # Guidance for Designated Experts
> 
> When processing a request for a Specification Required allocation
> the Designated Experts are expected to be able to find the
> relevant specification at a clearly stable URL.
> It is noted that many enterprise web sites do not maintain URLs
> over a long period of time, and a documented in a "wp-uploaded"
> section is highly likely to disappear.
> In addition Specifications that require a reader to click through
> any kind of marketing or legal agreement are not considered
> public.
> (This is the opinion of other corporate lawyers, who worry about
> what their employees might have agreed to)
> 
> The specification needs to be clearly written, and when the
> contents of the link type can contain an IPv4 or IPv6 header,
> then the octets between the beginning of the link type and the IP
> header needs to be very clearly specified in that document.
> 
> Specifications which are not publically available, but which may
> be obtained via liason agreements (such as to ITU-T, 3GPP, IEEE,
> etc.) are acceptable particularly if the document will be public
> eventually, but are discouraged.
> For other documents, the Designated Expert will need use their
> judgement, or consult the WG or an Area Director.
> 
> Linktypes may be allocated for specifications not publically
> available may be made within the First-Come/First-Served area.
> This includes specifications that might be classified.
> The minimal requirement is for a contact person for that link
> type.
> 


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doiven

Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-05.txt

Hi Eliot,

Thank you for addressing these. Please find some additional comments:

1. I created a PR for some minor points:
https://github.com/elear/opsawg-ol/pull/3/files: TLP + follow the guidance for
the list names.

2. I know that you don’t use the security template in 8520, but given that you
are introducing a reusable module I think that you should include it this time.
In particular, please see the template of the reusable grouping here:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-security-considerations-sect
(see the last two para).

3. From a YANG standpoint, I think that defining an “ol” feature would be
cleaner than the current use of “extensions”. I know that this is inherited
from 8520, but a clarification is needed here, especially that the grouping is
a reusable one.

4. You may check with netmod whether they have any preference about keeping the
ol grouping as part of the mud extension or be defined as a separate module.

Cheers,
Med

De : Eliot Lear
Envoyé : samedi 27 avril 2024 13:22
À : BOUCADAIR Mohamed INNOV/NET ; Michael
Richardson ; opsawg@ietf.org; m...@ietf.org
Objet : Re: [Mud] [OPSAWG] I-D Action: draft-ietf-opsawg-ol-05.txt

Hi Med,

I attempted to whack your changes into the draft. Carsten's merged the copy,
so for ease of reading (and diffing) I'll post an update for your
consideration. Michael, I don't think it's necessary in this case to update
8520 because we are indeed creating a new namespace. However, this wasn't
properly indicated in the draft.

Eliot
On 23.04.2024 08:40,
mohamed.boucad...@orange.com wrote:

Hi all,

Like Michael, I'm puzzled about the development of this draft.

I raised comments back in 05/2021 that I reiterated during the call for
adoption:
https://mailarchive.ietf.org/arch/msg/opsawg/OlkjFOk55hB-29UG4FQaNbunXTY/ but
still see the same issues in 2024. Putting aside the list/leaf-list thing, the
other points are straightforward such as fixing a json example.

Cheers,

Med

-Message d'origine-

De : OPSAWG De la
part de Eliot Lear

Envoyé : lundi 22 avril 2024 20:02

À : Michael Richardson ;
opsawg@ietf.org;

m...@ietf.org

Objet : Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-

05.txt

On 22.04.2024 19:29, Michael Richardson wrote:

0) Why is this document still kicking around the WG?

(Too bad it doesn't have the word "mud" in the filename.)

1) I find the title confusing.

2) I don't think that AUGMENT does what you want, because YANG

is not

extensible in the way we are used to doing with IANA.

3) I think that you have to revise the MUD specification

itself.

internet-dra...@ietf.org wrote:

> Internet-Draft draft-ietf-opsawg-ol-05.txt is now

available. It is a work item

> of the Operations and Management Area Working Group

(OPSAWG) WG of the IETF.

> Title: Ownership and licensing statements in YANG

> Authors: Eliot Lear

> Carsten Bormann

> Name:draft-ietf-opsawg-ol-05.txt

> Pages: 8

> Dates: 2024-04-18

> Abstract:

> This memo provides for an extension to RFC 8520 that

allows MUD file

> authors to specify ownership and licensing of MUD files

themselves.

> This memo updates RFC 8520. However, it can also be

used for

> purposes outside of MUD, and the grouping is structured

as such.

> The IETF datatracker status page for this Internet-Draft

is:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2

Fdata

tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-

ol%2F&data=05%7C02%7Cmohame

d.boucadair%40orange.com%7C92093d31adb04e54433408dc62f660b8%7C90c

7a20a

f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638494057558027066%7CUnknown%7

CTWFp

bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV

CI6Mn

0%3D%7C0%7C%7C%7C&sdata=evbyUZ0QB67LVPRNDJMok1EDqirGGX3LRl5lcZBXY

%2FA%

3D&reserved=0

> There is also an HTML version available at:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2

Fwww.

ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ol-

05.html&data=05%7C02%7C

mohamed.boucadair%40orange.com%7C92093d31adb04e54433408dc62f660b8

%7C90

c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638494057558035784%7CUnk

nown%

7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw

iLCJX

VCI6Mn0%3D%7C0%7C%7C%7C&sdata=ALyUu59W4HpqkNgltW2MR3tMIP0Oy7g2lx0

eMO2B

WFw%3D&reserved=0

> A diff from the previous version is available at:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2

Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11

Hi Joel, 

Thank you for the review.

You got it right. Please see more context at [1].

I updated the text to address your review. Please check the diff [1]  and let 
me know if any further change is needed. Thanks.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/opsawg/g-cXqAHzazaA_gOf7Woxv2SiVJ4/

[2] 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt&url_2=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/genart-review/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt

> -Message d'origine-
> De : Joel Halpern via Datatracker 
> Envoyé : vendredi 3 mai 2024 05:01
> À : gen-...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Genart last call review of draft-ietf-opsawg-ipfix-tcpo-
> v6eh-11
> 
> Reviewer: Joel Halpern
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General
> Area Review Team (Gen-ART) reviews all IETF documents being
> processed by the IESG for the IETF Chair.  Please treat these
> comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>  2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cmoh
> amed.boucadair%40orange.com%7Cbfb8988782a541c5816808dc6b1d5145%7C
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503020857412204%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WIsBdbKOD9ZyF0j%2BZKnq6
> ke79zktUZ9q%2B5n2iW34U%2Fs%3D&reserved=0>.
> 
> Document: draft-ietf-opsawg-ipfix-tcpo-v6eh-11
> Reviewer: Joel Halpern
> Review Date: 2024-05-02
> IETF LC End Date: 2024-05-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is ready for publication as a Proposed
> Standard RFC
> 
> Major issues: None
> 
> Minor issues:
> The document uses the phrasing "If several extension header
> chains are
> observed in a Flow" in several places.  While I believe I
> figured out what
> was intended, it caused me difficulty.  Assuming I understood
> the intent, I
> would suggest defining a term "flow with varying header
> chain" as "a flow
> wherein different packets in the flow have a different
> sequence of
> extension header types codes."  And then use that term in the
> suitable
> places in the document.
> 
> Nits/editorial comments: None
> 


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] Genart last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08

Hi Robert,

Thanks for the review. 

The changes made to take into account your comment can be seen at: 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/udp-ipfix/draft-ietf-opsawg-tsvwg-udp-ipfix.txt&url_2=https://boucadair.github.io/udp-ipfix/Robert-Sparks-Review/draft-ietf-opsawg-tsvwg-udp-ipfix.txt.

Please see more context inline.

Cheers,
Med

> -Message d'origine-
> De : Robert Sparks via Datatracker 
> Envoyé : vendredi 3 mai 2024 17:55
> À : gen-...@ietf.org
> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Genart last call review of draft-ietf-opsawg-tsvwg-udp-
> ipfix-08
> 
> Reviewer: Robert Sparks
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General
> Area Review Team (Gen-ART) reviews all IETF documents being
> processed by the IESG for the IETF Chair.  Please treat these
> comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>  2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cmoh
> amed.boucadair%40orange.com%7C6d87cb3283c64ed6d19e08dc6b896870%7C
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503485103625289%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=adEyrIGMb6Q9ax9ZGQ2GzW%
> 2FsWbv2g1Dx7%2F0gUP0guH0%3D&reserved=0>.
> 
> Document: draft-ietf-opsawg-tsvwg-udp-ipfix-08
> Reviewer: Robert Sparks
> Review Date: 2024-05-03
> IETF LC End Date: 2024-05-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready with nits
> I am the assigned Gen-ART reviewer for this draft. The General
> Area Review Team (Gen-ART) reviews all IETF documents being
> processed by the IESG for the IETF Chair.  Please treat these
> comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>  2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cmoh
> amed.boucadair%40orange.com%7C6d87cb3283c64ed6d19e08dc6b896870%7C
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503485103636074%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FDTBvCsYxqbgHiEkXmhMU
> D9uXisLHgPnje4wrHvCanA%3D&reserved=0>.
> 
> Document: draft-ietf-opsawg-tsvwg-udp-ipfix-18
> Reviewer: Robert Sparks
> Review Date: 2024-05-03
> IETF LC End Date: 2024-05-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready with nits
> 
> Consider discussing, or point to existing considerations about,
> what should happen when you are exporting very large udp options
> (perhaps constructed maliciously to be as large as possible) and
> you are carrying the exported values over UDP (Section 10.3 of
> RFC7011) and run out of room.
> 

[Med] These considerations are not specific to this document and fall under the 
generic considerations in base spec 7011 (Section 10.3.3). After think about 
this, I added a new section called (ops considerations) with the following 
content: 

* moved the text about reduced-size encoding to that section
* encourage the use of reduced-size encoding in the presence of EXP/UEXP (that 
is the *ExID IEs) takes precedence and thus their flags can be ignored
* add a pointer to transport (including MTU) IPFIX cons.

Also, we are not mentioning misbehaving nodes may generate large amount of 
data, etc. because that falls as well under the generic cons in RFC7011:

   Direct DoS attacks can also involve state exhaustion, whether at the
   transport layer (e.g., by creating a large number of pending
   connections) or within the IPFIX Collecting Process itself (e.g., by
   sending Flow Records pending Template or scope information, or a
   large amount of Options Template Records, etc.).

Added an explicit pointer to section 11 of 7011.

> There are several references by section number into I-D.ietf-
> tsvwg-udp-options that have become stale. For instance the
> pointer to section 22 in the security considerations should be
> pointing to section 24.
> 
> 
[Med] Good catch. Thanks.


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 auth

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

Hi Watson,

Thank you for the review. 

The review will be ACKed in the next iteration: 
https://github.com/boucadair/udp-ipfix/pull/5/commits/d1ea84a92a972e4ed00f408fd70362c2101b26a9

Cheers,
Med

> -Message d'origine-
> De : Watson Ladd via Datatracker 
> Envoyé : dimanche 5 mai 2024 23:29
> À : sec...@ietf.org
> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org; watsonbl...@gmail.com
> Objet : Secdir last call review of draft-ietf-opsawg-tsvwg-udp-
> ipfix-08
> 
> 
> Reviewer: Watson Ladd
> Review result: Ready
> 
> I have reviewed this document as part of the security
> directorate's ongoing effort to review all IETF documents being
> processed by the IESG. These comments were written primarily for
> the benefit of the security area directors. Document editors and
> WG chairs should treat these comments just like any other last
> call comments.
> 
> The summary of the review is READY.
> 
> This document simply adds more information about a flow to IPFIX,
> that information being UDP extensions. It's no surprise that the
> securities considerations is appropriately short, and I found no
> reason to disagree.
> 
> Sincerely,
> Watson Ladd
> 


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] INTDIR Review of draft-ietf-opsawg-ipfix-fixes-08

Hi Donald,

Thanks for the review.

All good suggestions. I went with all of the suggestions, except the refs:
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/simple-ipfix-fixes/draft-ietf-opsawg-ipfix-fixes.txt&url_2=https://boucadair.github.io/simple-ipfix-fixes/Donald-Eastlake/draft-ietf-opsawg-ipfix-fixes.txt

Cheers,
Med

De : Donald Eastlake
Envoyé : lundi 6 mai 2024 00:08
À : int-...@ietf.org; int-...@ietf.org
Cc : draft-ietf-opsawg-ipfix-fixes@ietf.org; opsawg-cha...@ietf.org
Objet : INTDIR Review of draft-ietf-opsawg-ipfix-fixes-08

I am an assigned INT directorate reviewer for
. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/ .

Based on my review, if I was on the IESG I would ballot this document as NO
OBJECTION.

This is a straightforward document that fixes lots of inconsistencies and
glitches in the IPFIX IANA Information Element registry.

I did not find any significant issues or technical problems with this document.

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

Abstract: "a shortcoming" -> "shortcomings"

Abstract & Introduction: "calling" -> "citing" or "referencing"

Section 6.21.2: References to IEEE and ISO/IEC documents, if they are
worth including, should be real references.

Section 3, 2nd sentence: I think "should be" -> "is"

Section 4.4.2 & 4.5.2: although DCCP is included in the "e.g." list in
the last sentence of these sections, it is not included in their
Description paragraph and there is no reference to RFC 4340. These
should at least be consistent within the registry entry.

Section 6.10.2: listing RFC 3022 twice seems odd.

Section 9: This says to "update" the reference clause of the "IPFIX
Information Elements" registry with "this document". Suggest using
"add" rather than "update" as in

request IANA to add [this document] to the references for the
"IPFIX Information Elements" registry.
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com

Re: [OPSAWG] advancing PCAP drafts

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Michael Richardson 
> Envoyé : lundi 6 mai 2024 12:18
> À : BOUCADAIR Mohamed INNOV/NET ;
> opsawg@ietf.org
> Objet : Re: [OPSAWG] advancing PCAP drafts
> 
> 
> {please ignore unicast message I sent thirty seconds ago}
> 
> mohamed.boucad...@orange.com wrote:
> > I think that it would be useful to have a new column to
> easily tag the
> > status of an assignment. Deprecated ones can be marked as
> such using
> > that new column, instead of having this in the description.
> 
> okay, I couldn't quite understand this from the diff, but in
> principal I have no problem with that.

[Med] Actually, I didn't make that change in the PR as I wanted to discuss it 
first here. As you are Ok with it, so please update the table accordingly. 
Thanks.

> 
> > For the DE guidance, I'm afraid that the first part of your
> text is redundant with what is already in 8126, especially this
> part:
> 
> > For the Specification Required policy, review and approval
> by a
> > designated expert (see Section 5) is required, and the
> values and
> > their meanings must be documented in a permanent and
> readily
> > available public specification, in sufficient detail so
> that
> > interoperability between independent implementations is
> possible.
> 
> So, a reason why I wrote that slight redundant text is so that
> the engineer who is trying to get their marketing person to put
> the document out in a sane place, would have a single place to
> point to.

[Med] Yeah. I think the text in 8126 is well enough.

> But, if the WG feels that redundant, I can go with that.
> 
> --
> Michael Richardson , Sandelman Software
> Works
>  -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*

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]Re: Request to review draft-ietf-opsawg-tacacs-tls13

2024-05-07 Thread mohamed . boucadair

Hi Tiru,

Many thanks for the review. Forwarding it to the list, fwiw.

I trust the authors will follow up. See one comment inline.

Cheers,
Med

De : tirumal reddy 
Envoyé : mardi 7 mai 2024 15:17
À : BOUCADAIR Mohamed INNOV/NET 
Cc : draft-ietf-opsawg-tacacs-tl...@ietf.org
Objet : Re: Request to review draft-ietf-opsawg-tacacs-tls13


My comments on the use of TLS in the draft.

1.

   TACACS+ over TLS takes the protocol defined in [RFC8907], removes the
   option for MD5 obfuscation, and specifies the use of TLS (version 1.3
   or later) for transport using a new well-known default server port
   number.  The next sections provide further details and guidance.

Comments> I suggest to use normative language that TACACS+ MUST use TLS 1.3. 
You may want to add that "It is expected that TACACS+ as described in this 
document will work with future versions of TLS."
You may also want to say that earlier versions of TLS MUST NOT be used,

2. Implementations MUST support TLS 1.3 [RFC8446] and MAY permit TLS 1.3
   session resumption.  If resumption is supported, the resumption
   ticket_lifetime SHOULD be configurable, including a zero seconds
   lifetime.

Comment> Session resumption is an in-built feature of TLS 1.3 and I don't see 
the need to use "MAY".


3. This document makes no cipher suite recommendations, but
   recommendations can be found in the TLS Cipher Suites section of the
   Section 4.3 of [RFC9325].

Comment> I don't see a need to refer to RFC9325 (it is specific to (D)TLS 1.2).
[Med] My understand is that RFC covers 1.3 given that it says explicitly:

This BCP applies to TLS 1.3, TLS 1.2, and earlier versions.

The tacacs+ spec has also the following:

   Those implementing and deploying
   Secure TACACS+ must adhere to the recommendations relevant to TLS 1.3
   outlined in [RFC9325], or its subsequent versions.

   This document outlines additional restrictions permissible under
   [RFC9325].  For example, any recommendations referring to TLS 1.2,
  including the mandatory support, are not relevant for Secure TACACS+
   as TLS 1.3 or above is mandated.

  RFC9325 is referred to in several places in the document and the same comment 
applies.

4. 3.2.2.1.  TLS Certificate Path Verification

   Implementations MUST support certificate Path verification as
   described in [RFC5280].

   Because a peer could be isolated from a remote peer's Certificate
   Authority (CA), implementations MUST support certificate chains
   (a.k.a. bundles or chains of trust), where the entire chain of the
   remote's certificate is stored on the local peer.  TLS Cached
   Information Extension [RFC7924] SHOULD be implemented.  This MAY be
   augmented with Raw Public Keys [RFC7250].

Comment> Is it referring to PKIX-based authentication or use of local CA or 
both ? Please elaborate.
Comment> How will the client identify the server identity (domain name) ?
Comment> I am assuming the client MUST verify the chain of certificates up to a 
trust anchor as described in Section 6 of [RFC5280].  The client SHOULD use the 
default system or application trust anchors, unless otherwise configured.
Comment> Why "SHOULD" and not use "MUST" ?
Comment> What is the need to support raw public keys ?. The main security 
challenge with raw public keys is how to associate the public key with a 
specific entity and revocation (e.g., private key is compromised).

5.Device Identity based validation methods where the peer's identity is
   used in the certificate subjectName.  This is applicable in
   deployments where the device securely supports an identity which is
   shared with its peer.  This approach allows a peer's network location
   to be reconfigured without issuing a new client certificate.  Only
   the local server mapping needs to be updated.

Comment> You may want to leverage SAN instead of subjectName (for example, see 
https://www.rfc-editor.org/rfc/rfc8310.html#section-8.1).
Comment> I am not sure what you mean by "Network location based validation 
methods" ?

6.Implementations SHOULD support the TLS Server Name Indication
   extension (Section 3 of [RFC6066]), and SHOULD include the server
   domain name in the SNI "server_name" extension of the client hello.

Comment> Please explain the exception scenarios where SNI is not required.

7. If TLS Encrypted Client Hello becomes standardized and applicable to
   TLS 1.3, then it SHOULD be included in Secure TACACS+ implementation.

Comment> It will be a standard and ECH is already deployed. I don't think ECH 
is applicable to TACACS deployment (e.g., ECH will require a public provider, 
see https://www.ietf.org/archive/id/draft-ietf-tls-esni-18.html#section-3).

Cheers,
-Tiru

On Thu, 25 Apr 2024 at 13:24, 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Tiru,

Can you please review this document (draft-ietf-opsawg-tacacs-tls13-07 - 
TACACS+ TLS 
1.3) and 
share comments/suggestions you may have?

T

[OPSAWG]Re: RtgDir Last Call review of draft-ietf-opsawg-teas-attachment-circuit-11

Hi Donald, 

Thank you for the review. 

I like the suggestions. I went with almost all of them (except the one about 
the ToC) as you can see in the candidate version: 
https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt.

Cheers,
Med

> -Message d'origine-
> De : Donald Eastlake 
> Envoyé : vendredi 10 mai 2024 23:19
> À :  (rtg-...@ietf.org) 
> Cc : Routing Directorate ; draft-ietf-opsawg-
> teas-attachment-circuit@ietf.org; t...@ietf.org; Last Call
> 
> Objet : RtgDir Last Call review of draft-ietf-opsawg-teas-
> attachment-circuit-11
> 
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and
> IESG review, and sometimes on special request. The purpose of the
> review is to provide assistance to the Routing ADs. For more
> information about the Routing Directorate, please see
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwiki.ietf.org%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C02%7Cmohamed
> .boucadair%40orange.com%7C5e2654d5909a4f91feaa08dc7136edb5%7C90c7
> a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638509727928172271%7CUnkno
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DhlZd1ZXwBN4NpT1xyLrHtBMyYD
> K0zA7aUXpJ4cGc%2Fw%3D&reserved=0
> 
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with
> any other IETF Last Call comments that you receive, and strive to
> resolve them through discussion or by updating the draft.
> 
> Document: draft-ietf-opsawg-teas-attachment-circuit-11
> Reviewer: Donald Eastlake
> Review Date: 2024-05-08
> IETF LC End Date: date-if-known
> Intended Status: Standards Track
> 
> Summary:
> 
> This document is basically ready for publication but has nits
> that should be considered prior to publication.
> 
> This document specifies a YANG service data model for Attachment
> Circuits and a set of reusable groupings. I am not that deep a
> YANG expert but it seems to be in the right direction.
> 
> Comments:
> 
> I found the writing in this draft to be of good quality and
> readability. I previously review version -07 and it looks like
> the minor issues I found have been fixed and most, but not all,
> of the nits I found have been fixed.
> 
> No major issues found.
> 
> Minor Issues:
> 
> No minor issues found.
> 
> Nits:
> 
> The Table of Contents only goes down two levels, to Sections
> whose number is of the form n.m. But some sections in Sections 5
> are five levels deep (n.m.o.p.q). The ToC does not need to go all
> the way to level 5, but I think it should be extended to at least
> level 3.
> 
> Section 1.1, next to last paragraph: there is no reason to cite
> that the various identifiers used are ones intended for examples.
> Suggest deleting this paragraph.
> 
> Section 2: I suggest adding entries for PE, CE, and NF.
> 
> Section 5.2 under 'oper-status': "it is recommended to consider
> both administrative and operational service status values in
> conjunction."
> -> "considering administration and operational service status
> values
> together is recommended."
> 
> Section 5.2.2.2: "abovementioned" -> "above mentioned"
> 
> Section 7: two extra spaces that should be deleted:
>"nacm:default-deny- write"
>key- string
> 
> Section A.11.1, first paragraph: "permits to manage connectivity
> requirements" -> "permits managing connectivity requirements"
> 
> A.11.3, fourth bullet point: "permits to handle compute failures"
> -> "permits handling compute failures"
> 
> Suggest replacing the two occurrences of "leverages" with "uses".
> 
> All references to RFC 5798 should be replaced by references to
> RFC 9568.
> 
> The nits checker finds 56 lines too long but that is probably due
> to non-ASCII characters,
> 
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA  d3e...@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 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 a

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

Hi Paul,

Thank you for the review. The changes can be tracked at: Diff: 
draft-ietf-opsawg-ipfix-fixes-08.txt - 
draft-ietf-opsawg-ipfix-fixes.txt

Please see inline for more context.

Cheers,
Med

De : Aitken, Paul 
Envoyé : mercredi 8 mai 2024 11:42
À : drafts-expert-review-comm...@iana.org; BOUCADAIR Mohamed INNOV/NET 

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


This document is simply too long to review. I'm about half way through, and 
will not have time to complete the review before May 10th.



* 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



* In the Introduction, "some other parts" lacks context unless the reader is 
familiar with RFC9565, RFC7125, and the WG process that took place. So simply 
say, "some parts":

   When OPSAWG was considering [RFC9565] which updates [RFC7125], the WG

   realized that some other parts of the IANA IP Flow Information Export

   (IPFIX) registry ...



[Med] ACK.


* Typo in 4.1.2. NEW :

  See the assigned tranport protocol (e.g., TCP, UDP, DCCP, and

  SCTP) port numbers at https://www.iana.org/assignments/service-

  names-port-numbers.


Also, please retain the UDP, TCP, SCTP, DCCP ordering. Same for 4.2.2, 4.4.2, 
and 4.5.2.
See the assigned tranport protocol (e.g., TCP, UDP, DCCP, and SCTP) port 
numbers at
https://www.iana.org/assignments/service-names-port-numbers.

[Med] ACK


* 4.2.2. NEW

"destination" x2 :
Description: The destination port identifier in the transport protocol header. 
For transport protocols such as
UDP, TCP, SCTP, and DCCP, this is the source port number given in the 
respective header. This field MAY also
be used for future transport protocols that have 16-bit source port identifiers.

[Med] Good catch. Fixed.


* 4.4.2. NEW

There's no mention of DCCP in the description, nor reference to [RFC4340], 
though DCCP is mentioned in the last paragraph of Additional Information.

[Med] Already fixed that one when addressing Donald's review.


* 4.5.2. NEW

Traffic is sent from a source port, not to it:

The source port identifier to which the Exporting Process sends Flow 
information.

[Med] ACK.


There's no mention of DCCP in the description, nor reference to [RFC4340], 
though DCCP is mentioned in the last paragraph of Additional Information.

[Med] Already fixed that one when addressing Donald's review.



* 6.3.2. NEW

No, it's the "flow end reason" registry:

See the Classification Engine IDs registry available at 
[https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason].


[Med] ACK.


* 6.4.2. New

"See the NAT originating address realm registry at ..."
Additional Information: See the assigned NAT originating address realm at

[Med] ACK


* 6.5.2. New

"See the NAT Event Type registry at"
Additional Information: See the assigned NAT Event Types at

[Med] The OLD is correct, but I understand that echoing the registry name is 
explicit that this is about "assigned xxx values". Went with this modif.


* 6.6.2. NEW

"See the firewallEvent registry at"
Additional Information: See the assigned firewall events at

Same comment for many other sections. ie, where the text says, "Values are 
listed in the xyz registry.", the Additional Information should say, "See the 
xyz registry at ..."


[Med] ACK.


* 6.11.2 NEW

Please append [RFC5102] 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?


* Typo in 6.12.2. NEW :

   Additional Information:  See the assigned emelement data types at

  [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-

  information-element-data-types].



[Med] ACK.

* 6.13.2. NEW

The ; should be a . as "The special value" is a new sentence:

subregistry; the special value 0x00 (default) is used

[Med] ACK.


(Stopped at 6.14)

Ce message et ses pieces jointes peuven

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

Hi Paul,

Thank you for the careful review, as usual. Much appreciated!

The diff to track all the changes (including other reviewers) can be seen at: 
Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh-11.txt - 
draft-ietf-opsawg-ipfix-tcpo-v6eh.txt

Please see inline.

Cheers,
Med

De : Aitken, Paul 
Envoyé : mercredi 8 mai 2024 11:42
À : drafts-expert-review-comm...@iana.org; BOUCADAIR Mohamed INNOV/NET 

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


* 1.1

Add "the":

   Section 3 addresses these issues.  Also, the ipv6ExtensionHeaders IPFIX

   IE is deprecated in favor of the new IEs defined in this document.


[Med] ACK.

* 1.2

Add "the" :

   The specification of the tcpOptions IPFIX IE (209) does not:

[Med] ACK.

Should "option" be "options"? :

   *  Describe how some observed TCP options in a Flow can be exported

  using IPFIX.  Only TCP options having a Kind <= 63 can be exported

  in a tcpOptions IE.

[Med] Yes. Fixed.

Add "the" :

   Section 4 addresses these issues.  Also, the tcpOptions IE is deprecated

   in favor of the new IEs defined in this document.

[Med] OK


* 2

Is the indentation correct here? :

   Extension header chain:  Refers to the chain of extension headers

  that are present in an IPv6 packet.



  This term should not be confused with the IPv6 header chain, which

  includes the IPv6 header, zero or more IPv6 extension headers, and

  zero or a single Upper-Layer Header.

[Med] Yes


* 3.2

"the same" :

   Description:  The number of consecutive occurrences of the same

  extension header type in a Flow.

[Med] ACK


* 3.4

Add "ipv6ExtensionHeaderTypeCountList" :

  If several extension header chains are observed in a Flow, each

  header chain MUST be exported in a separate 
ipv6ExtensionHeaderTypeCountList IE.

[Med] ACK.

* 3.5

What if both ipv6ExtensionHeadersFull and ipv6ExtensionHeaderTypeCountList are 
exported?
[Med] The present of the limit will still be meaningful and reflects how 
ipv6ExtensionHeadersFull or ipv6ExtensionHeaderTypeCountList.

[Later] this is discussed in section 5.1, but that wouldn't be known from 
reading the IPFIX registry alone. The fact that these IEs are mutually 
exclusive should be added to both IE descriptions.

   Description:  When set to "false", this Information Element indicates

  that the exported extension headers information (e.g.,

  ipv6ExtensionHeadersFull or ipv6ExtensionHeaderTypeCountList) does

  not match the full enclosed extension headers

[Med] Not sure we need to put all the ops details in the description.


* 3.6

Change "identifying" to "to identify" :

  Exporting such information might help

  to identify root causes of performance degradation, including

  packet drops.

How would we know which ipv6ExtensionHeadersChainLength IE corresponds with 
which header chain?

  If several extension header chains are observed in a Flow, each

  header chain length MUST be exported in a separate

  ipv6ExtensionHeadersChainLength IE.

[Med] Good point. Added a new list IE to correlate these two as needed.


* 5.1

"Will" sounds like a detail of a particular implementation. More generally this 
should be a "MUST", a "SHOULD", or a "MAY":

   If an implementation determines that an observed packet of a Flow

   includes an extension header that it does not support, then the exact

   observed code of that extension header will be echoed in the

   ipv6ExtensionHeaderTypeCountList IE (Section 3.4).

[Med] Went with MUST


* 5.2

What does this mean? :

   If a TCP Flow contains packets with a mix of 2-byte and 4-byte

   Experiment IDs, the same Template Record is used with both

   tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs.



[Med] both IEs will be present.

* 6.1

It would be helpful to list the corresponding header bit values, and to list 
them in order (0, 1, 5) rather than 1, 5, 0:

   Figure 1 provides an example of reported values in an

   ipv6ExtensionHeadersFull IE for an IPv6 Flow in which only the IPv6

   Destination Options header (0) is observed.



   Figure 2 provides another example of reported values in an

   ipv6ExtensionHeadersFull IE for an IPv6 Flow in which the IPv6 Hop-

   by-Hop Options (1), Routing (5), and Destination Options (0) headers are

   observed.

[Med] ACK.


* 6.2

It would be helpful to list the corresponding header bit values:

   Figure 3 shows an example of reported values in a tcpOptionsFull IE

   for a TCP Flow in which End of Option List (0), Maximum Segment Size (2), and

   Window Scale (3) options are observed.

Please use the full 16-bit value, "0348" :

   1.  The tcpSharedOptionExID16 IE set to 0x0348454E to report observ

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

Hi Joe, 

Thank you for the excellent review. 

The changes to address the review can be seen here: 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/udp-ipfix/draft-ietf-opsawg-tsvwg-udp-ipfix.txt&url_2=https://boucadair.github.io/udp-ipfix/Joe-Review/draft-ietf-opsawg-tsvwg-udp-ipfix.txt

Please see inline for more context. 

Cheers,
Med

> -Message d'origine-
> De : Joseph Touch via Datatracker 
> Envoyé : mercredi 8 mai 2024 06:06
> À : int-...@ietf.org
> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Intdir last call review of draft-ietf-opsawg-tsvwg-udp-
> ipfix-08
> 
> 
> Reviewer: Joseph Touch
> Review result: Ready with Issues
> 
> Note that I previously performed an INTAREA early review on Jan
> 12, 2024.
> 
> This document sufficiently addresses the issues previously
> raised, with the exception below. It introduces no new concerns.
> 
> The sole remaining issue is the use of "unsigned256" as a data
> type. This is necessary to represent the potential bitfield to
> support all 256 possible UDP option Kind values. This document
> cites draft-ietf-opsawg-ipfix-tcpo-v6eh as defining this type (in
> Sec 8.3). That (tcpo-v6eh) document defines the range of this
> type correctly, but then refers back to RFC7011 Sec 6.1.1 to
> define the encoding. Unfortunately, RFC7011 defines encodings for
> unsigned integers only up to 64 bits.
> 
> This (udp-ipfix) document cites Section 6.2 of RFC7011 to define
> reduced size encodings of unsigned256, but RFC7011 defines those
> encodings only for 64, 32, and 16 bit unsigned integers.
> Additionally, those reductions apply only when the high-order
> byte(s) are all zero; for UDP options, the partitioning of
> options into SAFE and UNSAFE groups and the assignment of
> experiment codepoints to the highest values in both ranges
> suggests that these reduced size encodings may be of limited
> relevance.

Med] Good point. As you can see in 
https://mailarchive.ietf.org/arch/msg/opsawg/JJAD7ooBNe_gFHRUAiHmK24HBNk/, we 
already made changes so that reduced-size encoding can be used even in the 
presence of shared options; see specifically this part: 

==
[Med] These considerations are not specific to this document and fall under the 
generic considerations in base spec 7011 (Section 10.3.3). After think about 
this, I added a new section called (ops considerations) with the following 
content: 

* moved the text about reduced-size encoding to that section
* encourage the use of reduced-size encoding in the presence of EXP/UEXP (that 
is the *ExID IEs) takes precedence and thus their flags can be ignored
* add a pointer to transport (including MTU) IPFIX cons.
==

We can go one step further to export SAFE and UNSAFE options in separate IEs. 

> 
> At least one document needs to define unsigned256 normatively -
> this doc, tcpo-v6eh, or some other. That document needs to
> explain the byte order representation and reduced size encoding.

[Med] Makes sense. Removed the pointer to 6.1.1 of 7011 and copy/paste the 
encoding in the tcp-eh I-D.

> 
> This (udp-fix) document also uses the octetArray type, but then
> defines it as being interpreted as "16-bit fields" (Sec 4.2,
> 4.3). This should probably refer to unsigned16 values, but it's
> not clear that this is a valid use of octetArrays. Being able to
> read such an array as unsigned16 values may require half-word
> (16bit) or word (32bit) alignment, such that reading an
> unsigned16 from a misaligned offset may either result in an error
> or a misinterpreted
> (byte-swapped) value. Please provide an example of use of an
> octetArray as a list of multi-octet values in a published RFC or
> provide an alternate representation (or define one in detail).
> 

[Med] Please see 
https://mailarchive.ietf.org/arch/msg/opsawg/XUeSAPc22OkAPKGJwO54BN2H5wM/.

> Some additional minor suggestions:
> 
> Note that the "ex" in ExID already means "experimental option".
> It thus may be useful to consider shortening the name of the
> related two element IDs, e.g., reducing
> udpUnsafeExperimentalOptionExID to udpUnsafeExID and reducing
> udpSafeExperimentalOptionExID to udpSafeExID.

[Med] I prefer to keep the current names as we don't know if other IEs will be 
defined in the future to cover other aspects of these options.

> 
> Fig 2 shows the full unsigned256 field, but it is not clear why
> this is useful if the reduced length variant is sufficient. It
> might be useful to show just the appropriate byte.

[Med] The intent is to further insist on the reduced encoding.

> 
> 


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 ains

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

Hi Paul,

Thanks for the review.

Please see inline.

You may also see the diff that integrates your comments and intdir review: 
Diff: draft-ietf-opsawg-tsvwg-udp-ipfix.txt - 
draft-ietf-opsawg-tsvwg-udp-ipfix.txt.
 Your review on these changes is more than welcome.

Cheers,
Med

De : Aitken, Paul 
Envoyé : mercredi 8 mai 2024 11:42
À : drafts-expert-review-comm...@iana.org; BOUCADAIR Mohamed INNOV/NET 

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



* 3. UDP Options at a Glance

Add "to" :

e.g., to discover a path MTU or share timestamps

[Med] OK.



* 4. New UDP IPFIX Information Elements

The URLs in the "note" should be listed in the references. The note should say 
"to be updated / removed by the RFC editor".

[Med] Makes sense. Done.



* 4.2. and 4.3. / Description
The information is encoded in a set of 16-bit fields. Each 16-bit
field carries the observed ExID in an EXP option.
I mis-parsed this as if each 16-bit field carries an EXP option: "Each 16-bit 
field carries the observed ExID / in an EXP option."

It may be clearer as, "Each 16-bit field carries the ExID which was observed in 
an EXP option."

[Med] ACK.


* 4.2. and 4.3.

No mention is made of whether ordering is important or unimportant.

[Med] It is not important as we are silent about it.



* 5. Examples

Add "a":

If a udpOptions IE is exported for this Flow,

[Med] OK



* Under Figure 2:
Let us now consider a UDP Flow in which both SAFE and UNSAFE
Experimental options are observed. Let us also consider that the
observed SAFE Experimental options have ExIDs set to 0x9858 and
0xE2D4, and UNSAFE Experimental options have ExIDs set to 0xC3D9 and
0x9858.
The last 0x9858 should be 0x9658 to correspond with the following point 2 and 
Figure 4.

0x9858 and 0x9658 are very similar. Could more distinct values be used?

[Med] We are using the same value to exemplify that the same ExID may be 
present in both safe and unsafe shared options.


* Figure 3:
If udpOptions IE is exported for this Flow, then that IE will
have bits in positions 127 (EXP) and 254 (UEXP) set to 1 (Figure 
3).

The goal is to set bits 127 and 254, so it's confusing to see what appears to 
be bits 1 and 128 set:

MSB LSB

12  25

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

+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+

|X|1|X|X|   |X|X|X|X|X|X|X|X|X|X|X|1|X|X|   |X|X|X|X|X|X|X|

+-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+

Intuitively one would expect to see these bits:

MSB LSB

12  25

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

+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+

|X|X|X|X|   |X|X|X|X|X|X|X|X|X|X|1|X|X|X|   |X|X|X|X|X|1|X|

+-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+

However since bit 2^n is set for option n, the problem is really with the 
misleading bit numbering in the figure.

ie, the example would be clearer without the numbering.
[Med] Made some changes. Hope this is better.

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: Secdir last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11

Hi Tero, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Tero Kivinen via Datatracker 
> Envoyé : jeudi 9 mai 2024 17:35
> À : sec...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Secdir last call review of draft-ietf-opsawg-ipfix-tcpo-
> v6eh-11
> 
> Reviewer: Tero Kivinen
> Review result: Has Issues
> 
> I have reviewed this document as part of the security
> directorate's ongoing effort to review all IETF documents being
> processed by the IESG.  These comments were written primarily for
> the benefit of the security area directors.  Document editors and
> WG chairs should treat these comments just like any other last
> call comments.
> 
> This document redefines the IPFIX IEs for IPv6 extension headers
> and TCP options to allow more data to be exported.
> 
> Issues:
> 
> In section 7 the text claims that "This document does not add new
> security considerations for exporting IES.", but as this document
> allows more information to be exported, there is also possibility
> that more data that was not available, thus there might be new
> security considerations.

[Med] Please note that we have this sentence right before the one you quoted to 
call out new threats: 

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.

> 
> For example this allows seeing multiple same extension headers,
> etc, thus there should be additional considerations.
> 
> Perhaps adding text saying that as this document allows more data
> to be available and some of that data might be sensitive, the
> implementations needs to take this into account when exporting
> data".

[Med] I think the text I quoted above is an example of what is sensitive. 
Unless there is a specific item to specifically list, the guards in the base 
specs are sufficient.

> 
> --
> 
> In section 8.4 if the IANA is automatically allocating next bit
> for each new IPv6 Extension Header, is there still separate
> expert review done for this automatic allocation or not?

[Med] No. The nominal mode won't involve a DE because mirroring will be 
sufficient to reflect (new, modification, deprecate, etc.). "otherwise" is a 
catchup to cover cases where modifications are local to the registry, not the 
parent one. For example, we do have two entries for fragments, while only one 
protocol number is used for fragments in the parent EH registry. Thanks.

 What
> happens if the experts in new registry do not allow registration
> for the extension header that was added to the IPv6 Extension
> Headers registry?
> 
> If implementation then sees that new IPv6 extension header that
> was allocated by IANA, but which is not in the IPFIX subregistry,
> how does it fill the bitfield?

[Med] made this change to make the behavior explicit: 

OLD:
If an implementation determines that an observed packet of a Flow includes an 
extension header that it does not support, then the exact observed code of that 
extension header MUST be echoed in the ipv6ExtensionHeaderTypeCountList IE 
(Section 3.4).

NEW:
If an implementation determines that an observed packet of a Flow includes an 
extension header (including an extension header that it does not support), then 
the exact observed code of that extension header MUST be echoed in the 
ipv6ExtensionHeaderTypeCountList IE (Section 3.4).


> 
> Also when new IPv6 extension headers are added, all
> implementations of IPFIX needs to be updated to map the protocol
> number to the bit, thus they can't add new extension headers
> until they are updated with the mapping.

[Med] This is not required for ipv6ExtensionHeaderTypeCountList IE. 

> 
> -
> -
> 
> Nits:
> 
> --
> In section 1.1
> 
> Write out the [RFC8200] in first bullet, i.e., change to:
> 
>*  Cover the full extension headers' range (Section 4 of IPv6
>   Specification [RFC8200]).
> 

[Med] I will keep the OLD.

> --
> 
> In section 1.1
> 
>*  Specify how to automatically update the IANA IPFIX registry
>   ([IANA-IPFIX]) when a new value is assigned in [IANA-EH].
> Only a
> 
> I think the [IANA-EH] here should be properly spelled out, i.e.,
> change the text to "when a new value is assigned in the IANA IPv6
> extension header types registry [IANA-EH]".

[Med] Done.

> 
> Also the text:
> 
>   For example, the ipv6ExtensionHeaders IE
>   can't report some IPv6 EHs, specifically 139, 140, 253, and
> 254.
> 
> 
> should not use numbers, but instead of names of those extension
> headers, i.e., it should say "specifically extension headers for
> Host Identity and Shim6 Protocol, or extension headers for
> experim

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

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]Re: [Ie-doctors] [IANA #1363824] Expert review for draft-ietf-opsawg-tsvwg-udp-ipfix (ipfix)

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]Re: shepherd review for draft-boro-opsawg-teas-common-ac

Hi Reza,

Thank you for preparing the writeup.

Please see inline.

Cheers,
Med

De : Rokui, Reza
Envoyé : lundi 13 mai 2024 21:35
À : Joe Clarke (jclarke) ; opsawg@ietf.org; BOUCADAIR
Mohamed INNOV/NET ; Wubo (lana)
; Richard Roberts ; Oscar González
de Dios ;
samier.barguil_gira...@nokia.com; Rokui, Reza
Objet : shepherd review for draft-boro-opsawg-teas-common-ac

Hi authors,

I am document shepherd for draft-boro-opsawg-teas-common-ac. I am preparing the
shepherd writeup and have following questions.

Question 8. Describe reviews and automated checks performed to validate
sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc;

[Med] pyang is integrated in our tooling to validate the YANG module. This is
also reflected in the Datatracker: 0 errors, 0
warnings

* Referring to
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-10.txt
. It seems there a few warnings and errors. Are these resolved? If so, please
send a summary.

[Med] Most are false negatives. The only valid one is the RFC 2119 boilerplate
text. Will remove it in the next iteration.

Question 15. Should any informative references be normative or vice-versa? See
the [IESG
Statement on Normative and Informative References][16].

* Please confirm this

[Med] I think we are OK, but please let us know if we misclassified any.

Question 16. List any normative references that are not freely available to
anyone. Did
the community have sufficient access to review any such normative
references?

* [ISO10589]. Is this reference essential to be part of the RFC?
[Med] Yes, because this is the authoritative ref for ISIS.

Question 17. Are there any normative downward references (see [RFC 3967][9] and
[BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.
- Please comment on following normative RFCs:
RFC 8174 category is BCP
RFC 7348 category is Informational and is already in DOWNREF registry
RFC 3688 category is BCP
RFC 2119 category is BCP

[Med] ACK. I confirm in particular that 7348 is already in the DOWNREF registry.

Question 19. Will publication of this document change the status of any
existing RFCs? If
so, does the Data tracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

* IMO the answer is NO. Please confirm.

[Med] ACK.

Reza

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: I-D Action: draft-ietf-opsawg-teas-common-ac-11.txt

Hi all, 

This version addresses the comment from Reza. 

No other issue was raised during the WGLC for this document.

Cheers,
Med

> -Message d'origine-
> De : internet-dra...@ietf.org 
> Envoyé : mardi 14 mai 2024 15:42
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : [OPSAWG]I-D Action: draft-ietf-opsawg-teas-common-ac-
> 11.txt
> 
> 
> Internet-Draft draft-ietf-opsawg-teas-common-ac-11.txt is now
> available. It is a work item of the Operations and Management
> Area Working Group (OPSAWG) WG of the IETF.
> 
>Title:   A Common YANG Data Model for Attachment Circuits
>Authors: Mohamed Boucadair
> Richard Roberts
> Oscar Gonzalez de Dios
> Samier Barguil Giraldo
> Bo Wu
>Name:draft-ietf-opsawg-teas-common-ac-11.txt
>Pages:   57
>Dates:   2024-05-14
> 
> Abstract:
> 
>The document specifies a common Attachment Circuits (ACs) YANG
>module, which is designed with the intent to be reusable by
> other
>models.  For example, this common model can be reused by
> service
>models to expose ACs as a service, service models that require
>binding a service to a set of ACs, network and device models
> to
>provision ACs, etc.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-teas-common-
> ac%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3d89952e868
> c42f2ae4f08dc741ba46e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> 7C638512909268878667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata
> =bGefrT%2F5rao1EyI6yj%2Bwjv9gUK6oJgg7G3pGOQfVz08%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-teas-common-ac-
> 11.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3d89952e8
> 68c42f2ae4f08dc741ba46e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C638512909268886563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sda
> ta=o423%2FBB1r21BA811aEyj%2FybcBigzDumZKBGvJMOPgDk%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-teas-
> common-ac-
> 11&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3d89952e868c42
> f2ae4f08dc741ba46e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38512909268890742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3V
> HXxbkxWpIOhyyIFR5NlTWQ5YelQOtrHRsY%2F15aIdo%3D&reserved=0
> 
> 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

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: I-D Action: draft-ietf-opsawg-teas-attachment-circuit-12.txt

Hi all, 

This version takes into account the rtg-dir review (Thanks Donald). We also 
fixed some bugs and updated an example to better illustrate the use of 
protection for both user and data planes (appendix). 

No other issues were raised during the WGLC.

Cheers,
Med

> -Message d'origine-
> De : internet-dra...@ietf.org 
> Envoyé : mardi 14 mai 2024 15:58
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : I-D Action: draft-ietf-opsawg-teas-attachment-circuit-
> 12.txt
> 
> 
> Internet-Draft draft-ietf-opsawg-teas-attachment-circuit-12.txt
> is now available. It is a work item of the Operations and
> Management Area Working Group (OPSAWG) WG of the IETF.
> 
>Title:   YANG Data Models for Bearers and 'Attachment
> Circuits'-as-a-Service (ACaaS)
>Authors: Mohamed Boucadair
> Richard Roberts
> Oscar Gonzalez de Dios
> Samier Barguil Giraldo
> Bo Wu
>Name:draft-ietf-opsawg-teas-attachment-circuit-12.txt
>Pages:   144
>Dates:   2024-05-14
> 
> Abstract:
> 
>This document specifies a YANG service data model for
> Attachment
>Circuits (ACs).  This model can be used for the provisioning
> of ACs
>before or during service provisioning (e.g., Network Slice
> Service).
>The document also specifies a service model for managing
> bearers over
>which ACs are established.
> 
>Also, the document specifies a set of reusable groupings.
> Whether
>other service models reuse structures defined in the AC models
> or
>simply include an AC reference is a design choice of these
> service
>models.  Utilizing the AC service model to manage ACs over
> which a
>service is delivered has the advantage of decoupling service
>management from upgrading AC components to incorporate recent
> AC
>technologies or features.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-teas-attachment-
> circuit%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb3a4fb
> 0715a643f8ef3c08dc741e051c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C638512919479655604%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&
> sdata=R4wfsvRpSXKT1V2K1TLMcZEb9bD%2FR0Sb4Pq%2Fpgs6C3U%3D&reserved
> =0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-teas-attachment-
> circuit-
> 12.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb3a4fb071
> 5a643f8ef3c08dc741e051c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C638512919479663819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sda
> ta=FIOqwxrBEcVJGta4eO%2BcYkBEfR4Uth1SGmvFxLT0yHI%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-teas-
> attachment-circuit-
> 12&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb3a4fb0715a643
> f8ef3c08dc741e051c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38512919479669215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XO
> gVEuDzthDxbHnXe4lF7ztuJMr3bQ1X8AbjwwNLwg0%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list -- i-d-annou...@ietf.org To unsubscribe
> send an email to i-d-announce-le...@ietf.org

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: I-D Action: draft-ietf-opsawg-ntw-attachment-circuit-10.txt

Hi all,

This version addresses the received WGLC comments:
* define peer-groups at the network level (received this comment offline from 
Oscar and Felipe)
* update the VRRP RFC (echo the rtgdir review comment on the ACaaS) 

No other WGLC comment is pending. 

Cheers,
Med

> -Message d'origine-
> De : internet-dra...@ietf.org 
> Envoyé : mardi 14 mai 2024 16:04
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : I-D Action: draft-ietf-opsawg-ntw-attachment-circuit-
> 10.txt
> 
> 
> Internet-Draft draft-ietf-opsawg-ntw-attachment-circuit-10.txt is
> now available. It is a work item of the Operations and Management
> Area Working Group (OPSAWG) WG of the IETF.
> 
>Title:   A Network YANG Data Model for Attachment Circuits
>Authors: Mohamed Boucadair
> Richard Roberts
> Oscar Gonzalez de Dios
> Samier Barguil Giraldo
> Bo Wu
>Name:draft-ietf-opsawg-ntw-attachment-circuit-10.txt
>Pages:   104
>Dates:   2024-05-14
> 
> Abstract:
> 
>This document specifies a network model for attachment
> circuits.  The
>model can be used for the provisioning of attachment circuits
> prior
>or during service provisioning (e.g., VPN, Network Slice
> Service).  A
>companion service model is specified in I-D.ietf-opsawg-teas-
>attachment-circuit.
> 
>The module augments the 'ietf-network' and the Service
> Attachment
>Point (SAP) models with the detailed information for the
> provisioning
>of attachment circuits in Provider Edges (PEs).
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ntw-attachment-
> circuit%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9aea90
> 0b867445e10cb108dc741ede87%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C638512923129704859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&
> sdata=M3TGiKkEiC5fWfnpkYRptnVwVuQ5yGbG9A3zud%2FCCsU%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ntw-attachment-
> circuit-
> 10.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9aea900b8
> 67445e10cb108dc741ede87%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C638512923129713242%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sda
> ta=96O2C85UmjfNCTOKpTsTWhniXU2yBy9crSKK6pg8n2Q%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-ntw-
> attachment-circuit-
> 10&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9aea900b867445
> e10cb108dc741ede87%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38512923129718043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tM
> saz%2FIKaq%2FM3owJBmtm0PfnLLHcoK3vRkHLauDiErk%3D&reserved=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list -- i-d-annou...@ietf.org To unsubscribe
> send an email to i-d-announce-le...@ietf.org

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: [Last-Call] Intdir last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08

2024-05-15 Thread mohamed . boucadair

Hi Joe,

Thank you for the follow-up.

A candidate version can be seen at: Diff: draft-ietf-opsawg-tsvwg-udp-ipfix.txt
-
draft-ietf-opsawg-tsvwg-udp-ipfix.txt

Please see inline.

Cheers,
Med

De : to...@strayalpha.com
Envoyé : mercredi 15 mai 2024 04:13
À : BOUCADAIR Mohamed INNOV/NET
Cc : int-...@ietf.org; draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org;
last-c...@ietf.org; opsawg@ietf.org
Objet : Re: [Last-Call] Intdir last call review of
draft-ietf-opsawg-tsvwg-udp-ipfix-08

Hi, Med,

I still have issue with the same two key parts:

1. This doc refers to unsigned192.

[Med] Before defining the unsigned192, I first considered reusing unsigned256 +
mandate that 64bits to be always set to zero. These leading zeros will thus be
dropped per the reduced size encoding.

- That is not a native data type of any known computer. It needs
to be defined.
[Med] Unsigned192 structure is used in many contexts (e.g., U192 in
crypto_bigint - Rust
(bsx.fi)).
- Reduced-size encoding per RFC7011 does not apply, unless you are
restricting them to 64, 32, 16, and 8.
[Med] There is no such restriction because of this part in the base spec:

This behavior is indicated by the Exporter by specifying a size in

the Template with a smaller length than that associated with the

assigned type of the Information Element.

2. Neither unsigned64 nor unsigned192 are compatible with octetArray as used in
this document, AFAICT
- octetArray would be for a sequence of unsigned64s, for example,
but not for bytes that might be interpreted in different ways
depending on length

It would be useful to explain why the safe and unsafe options are split (i.e.,
to support reduced-size encoding when both are in use).
[Med] Added a note about this.

The only approach that I think is compatible with RFC7011 is:

- use an octetArray and explain its length and mapping (e.g., of
unsigned8 values), representing the values 0…256 as consecutive groups of 8,
truncated when the remaining bytes are all zeros

[Med] This is not an option. All bitfield IEs in IPFIX are defined as unsigned
data types.
OR
- define safe as three unsigned64s, each potentially using
reduced-size encoding
[Med] We already considered this in the past
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-tsvwg-udp-ipfix/03/,
but changed the design because Benoît Claise rightfully pointed to a an issue
with reordering in IPFIX.

==
* Description: Observed UDP options of a Flow. The information is
encoded in a set of bit fields. Multiple instances of the
udpOptions IE are included to cover the 0-255 range (Figure 2);
each 64 values are mapped to an IE with th order preserved.
Options are mapped to bits according to their option numbers.
Option number X is mapped to bit X[64] of the IE instance
determined by the order "1+1[X/64]". A bit is set to 1 (or 0) if
the corresponding UDP option is observed (or not). A udpOptions
IE instance MAY be ommited if there is no ambiguity to determine
the position of an observed UDP option. For example, (1) if only
option kinds =<63 are observed, then only one udpOptions IE
instance is included, (2) if only option kinds =<127 are observed,
then two udpOptions IEs instances are included, (3) if some option
kinds =<63 while others are >=192 are observed, then four
udpOptions IE instances are included with the second and third IE
instances are both set to 0, etc.

* Abstract Data Type: unsigned64
==

See additional notes below.

Joe

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

On May 13, 2024, at 8:46 AM,
mohamed.boucad...@orange.com wrote:

Hi Joe,

Thank you for the excellent review.

The changes to address the review can be seen here:
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/udp-ipfix/draft-ietf-opsawg-tsvwg-udp-ipfix.txt&url_2=https://boucadair.github.io/udp-ipfix/Joe-Review/draft-ietf-opsawg-tsvwg-udp-ipfix.txt

Please see inline for more context.

Cheers,
Med

-Message d'origine-
De : Joseph Touch via Datatracker mailto:nore...@ietf.org>>
Envoyé : mercredi 8 mai 2024 06:06
À : int-...@ietf.org
Cc :
draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org;
last-
c...@ietf.org; opsawg@ietf.org
Objet : Intdir last call review of draft-ietf-opsawg-tsvwg-udp-
ipfix-08

Reviewer: Joseph Touch
Review result: Ready with Issues

Note that I previ

[OPSAWG]Re: Shepherd review for draft-ietf-opsawg-ntw-attachment-circuit

2024-05-15 Thread mohamed . boucadair

Hi Krzysztof, 

Thank you for the review.

Can you please check and let us know if any further change is needed: 
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-ntw-attachment-circuit&url_2=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-ntw-attachment-circuit.txt?
 Thanks.

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Krzysztof Szarkowicz
> 
> Envoyé : mercredi 15 mai 2024 14:41
> À : Joe Clarke (jclarke) ; opsawg@ietf.org
> Cc : opsawg-cha...@ietf.org
> Objet : [OPSAWG]Shepherd review for draft-ietf-opsawg-ntw-
> attachment-circuit
> 
> 
> Resending to the WG list
> 
> 
> 
> > On May 2, 2024, at 11:26, Krzysztof Szarkowicz
>  wrote:
> >
> > Hi,
> >
> >
> > I have been asked to do the shepherd's review for draft-ietf-
> opsawg-ntw-attachment-circuit document, with the intended traget
> status "Standards Track". "Standards Track" is the appropriate
> track for drafts defining Yang models, so it is appropriate for
> this draft.
> >
> > In general, the document is in a good shape. It is clearly
> written, complete, correctly designed, and ready to be handed off
> to the responsible Area Director. I believe this draft (in
> combination with 3 other AC related drafts: I-D.ietf-opsawg-teas-
> common-ac, I-D.ietf-opsawg-teas-attachment-circuit, I-D.ietf-
> opsawg-ac-lxsm-lxnm-glue) for AC provisioning, which decouples
> the bearer from the services itself is very useful for service/AC
> provisioning, including use cases like for example network
> slicing or services with SLA provisioning.
> >
> > Feedback in the WG mailing list for this draft is positive, and
> there is a broad agreement for support of this draft, without
> strong controversy or extreme discontent.
> >
> > The OPSA WG AC work was discussed externally and is cross-
> referenced by 3GPP (3GPP TS 28.541 Rel 18.5 onwards), O-RAN
> Alliance (O-RAN.WG9.XTRP-MGT.0-R003-v08.00 onwards) and TEAS WG
> draft-ietf-teas-ietf-network-slice-nbi-yang. This draft has
> undergone RTGDIR LC, as well as Yangdoctors early reviews, which
> declared the draft to be ready.

[Med] I would mention in the writeup the following as well:

To ensure cross-WG reviews:

* The call for adoption and WGLC for the document were also cced to TEAS WG.
* Progress status of the specification effort was shared with TEAS WG during 
IETF#116 
(https://datatracker.ietf.org/meeting/116/materials/slides-116-teas-14-bearers-attachment-circuits-saps-00)IETF#117)
 and 
(https://datatracker.ietf.org/meeting/117/materials/slides-117-teas-attachment-circuits-updates-next-steps-00).
  

> >
> > The IPR call for the draft was issued, with responses from
> relevant parties (authors, contributors). Authors/contributors
> agreed to be listed in the draft. There are five authors listed
> in the draft, which adheres to general IETF rule fo maximum five
> authors.
> >
> > One of the normative reference [IEEE802.1Qcp] might not be
> freely available to anyone. However, typically, the community
> have sufficient access to review this reference. Two other
> normative references are IETF drafts. However, undergoing WG LC
> at the same time as this draft.
> >
> > Publication of this draft will not change status of existing
> RFCs. All aspects of the draft requiring IANA assignments are
> associated with the appropriate reservations in IANA registries.
> Any referenced IANA registries have been clearly identified. Each
> newly created IANA registry specifies its initial contents,
> allocations procedures, and a reasonable name (see RFC 8126).
> >
> >
> >
> > I have just some nits and some minor clarification questions.
> >
> >
> >
> >
> >
> >
> > Section 1
> >
> > Figure 1 must be corrected in html version of the document
> (near right SAP in PE1 and two right SAPs in PE4). In text
> version this figure is OK.
> >

[Med] Tweaked the figure so the aavg rendering works.

> >
> > Section 4
> >
> > s/Typically, AS Border Routers (ASBRs) of each network is
> directly connected to an ASBR of a neighboring network/Typically,
> AS Border Routers (ASBRs) of each network are directly connected
> to ASBRs of a neighboring network
> >
> > Figure 4 in html version connects network 2# and Network 3#,
> while in text version doesn't interconnect these networks. Must
> be fixed in html version.
> >

[Med] ACK.

> >
> > Section 5.1
> >
> > s/a SAP is an abstraction of the network reference points/a SAP
> is an abstraction of the network reference point
> >
> > s/Indicate for each individual ACs one or a subset of the
> CEs/Indicate for each individual AC one or a subset of the CEs
> >

[Med] ACK

> >
> > Section 5.3.
> >
> > IS-IS link metric is 24-bit, while IS-IS path/prefix metric is
> 32-bit long (in the model uint16 is used) -> this must be fixed
> in the model
> >
> > IS-IS has 'mode', while OSPF doesn't have 'mode'. In both cases
> (IS-IS and OSPF), 'mode' (e.g. active/passive) is meaningful.
> Further, another type of interface mode is e.g. point-to-poin

[OPSAWG]Re: shepherd review for draft-boro-opsawg-teas-common-ac

2024-05-15 Thread mohamed . boucadair

Hi Reza,

Thank you for the review.

We don’t provide the full structure but snippets per the guidance in 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-tree-diagrams.

We provided the following in Section 4:

==
   The full tree diagram of the module can be generated using the
   "pyang" tool [PYANG] with "-f tree --tree-print-groupings" command-
   line parameters.  That tree is not included here because it is too
   long (Section 3.3 of [RFC8340]).  Instead, subtrees are provided for
   the reader's convenience.

  The full tree of the "ietf-ac-common" module is available at
  [AC-Common-Tree].
==

Cheers,
Med

De : Rokui, Reza 
Envoyé : mercredi 15 mai 2024 21:29
À : BOUCADAIR Mohamed INNOV/NET ; Joe Clarke 
(jclarke) ; opsawg@ietf.org; Wubo (lana) 
; Richard Roberts ; Oscar González 
de Dios ; 
samier.barguil_gira...@nokia.com; Rokui, Reza 
Objet : Re: shepherd review for draft-boro-opsawg-teas-common-ac


Thanks Med.

One more question.

9. Based on the shepherd's review of the document, is it their opinion that this
   document is needed, clearly written, complete, correctly designed, and ready
   to be handed off to the responsible Area Director?

[Reza]  The document is well-written. Having said that the following suggestion 
communicated with authors.
- Any reason that the tree format of "module ietf-ac-common" is not included. 
IMO, it provides more clarity to the reader.

Reza

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, May 14, 2024 at 9:05 AM
To: Rokui, Reza mailto:rro...@ciena.com>>, Joe Clarke 
(jclarke) mailto:jcla...@cisco.com>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>, Wubo (lana) 
mailto:lana.w...@huawei.com>>, Richard Roberts 
mailto:rrobe...@juniper.net>>, Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>,
 samier.barguil_gira...@nokia.com 
mailto:samier.barguil_gira...@nokia.com>>
Subject: [**EXTERNAL**] RE: shepherd review for draft-boro-opsawg-teas-common-ac
Hi Reza,

Thank you for preparing the writeup.

Please see inline.

Cheers,
Med

De : Rokui, Reza mailto:rro...@ciena.com>>
Envoyé : lundi 13 mai 2024 21:35
À : Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; 
opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; Wubo 
(lana) mailto:lana.w...@huawei.com>>; Richard Roberts 
mailto:rrobe...@juniper.net>>; Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 samier.barguil_gira...@nokia.com; 
Rokui, Reza mailto:rro...@ciena.com>>
Objet : shepherd review for draft-boro-opsawg-teas-common-ac


Hi authors,

I am document shepherd for draft-boro-opsawg-teas-common-ac. I am preparing the 
shepherd writeup and have following questions.

Question 8. Describe reviews and automated checks performed to validate 
sections of the
   final version of the document written in a formal language, such as XML code,
   BNF rules, MIB definitions, CBOR's CDDL, etc;

[Med] pyang is integrated in our tooling to validate the YANG module. This is 
also reflected in the Datatracker: 0 errors, 0 warnings 
[datatracker.ietf.org]


· Referring to  
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-10.txt
 
[author-tools.ietf.org]
 . It seems there a few warnings and errors. Are these resolved? If so, please 
send a summary.


[Med] Most are false negatives. The only valid one is the RFC 2119 boilerplate 
text. Will remove it in the next iteration.

Question 15. Should any informative references be normative or vice-versa? See 
the [IESG
Statement on Normative and Informative References][16].

· Please confirm this

[Med] I think we are OK, but please let us know if we misclassified any.

Question 16. List any normative references that are not freely available to 
anyone. Did
the community have sufficient access to review any such normative
references?

· [ISO10589]. Is this reference essential to be part of the RFC?
[Med] Yes, because this is the authoritative ref for ISIS.

Question 17. Are there any normative downward references (see [RFC 3967][9] and 
[BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.
-  Please comment on following normative RFCs:
RFC 8174 category is BCP
RFC 7348 category is Informational and

[OPSAWG]Re: Request to review draft-ietf-opsawg-tacacs-tls13

2024-05-16 Thread mohamed . boucadair

Hi Valery,

(ccing the OPSAWG to have a public record of your excellent review).

All good points. Many thanks.

I trust the authors will follow up SOON.

Please see some comments from my side.

Cheers,
Med

De : Valery Smyslov 
Envoyé : jeudi 16 mai 2024 15:24
À : BOUCADAIR Mohamed INNOV/NET 
Cc : draft-ietf-opsawg-tacacs-tl...@ietf.org
Objet : RE: Request to review draft-ietf-opsawg-tacacs-tls13


Hi Med, all,

I finally reviewed the draft.

I think that the document is in a good shape. It's understandable and easy to 
read.
Some polishing is needed though.

I also think that it's worth to circulate this document in the UTA WG asking 
for reviews.
[Med] We need to make sure UTA WG is cced in the WGLC.

There are many much more knowledgeable people than I am.

Issues (both technical and editorial).

  1.  Perhaps the name of the document should be "TACACS+ over TLS 1.3" or 
"Using TLS 1.3 to secure TACACS+"?
  2.  Section 3.2 mentions "Single Connection Mode" which is not defined in 
this draft. Perhaps an addition of a reference to RFC 8907 Section 4.3 would be 
helpful for those readers (like me), who are not familiar with TACACS+?
  3.  Section 3.2: in the sentence "If Single Connection Mode has been 
negotiated, it might remain open after a successful session, until an error or 
an inactivity timeout occurs." perhaps s/session/session conclusion ?
  4.  Section 3.2.1: I think that the proper name of the section should be 
"Cipher Suites Requirements"
  5.  Section 3.2.1: actually referencing Section 4.3 of RFC9325 for cipher 
suite recommendations is misleading, since that section contains no 
recommendations and refers to the RFC 8446 Section 9.1 instead, which is 
already mentioned above.
  6.  Section 3.2.2: The text "Unless disabled by configuration, a peer MUST 
disconnect any peer that presents an invalid TLS Certificate." in my reading 
implies that peer is first connected and then disconnected if it presents an 
invalid TLS Certificate. How can this happen? TLS connection just should not 
succeed in this case in my opinion... Am I missing something?
  7.  Section 3.2.2: referencing RFC 7250 is a bit problematic, since it 
defines using RPKs for TLS 1.2 only (and thus contains TLS 1.2 specific 
information). RPKs is also supported in TLS 1.3, but referencing this support 
is not an easy task - there is no dedicated section in RFC 8446... I don't have 
any good proposals here, perhaps just add reference to 8446 in addition to 7250.
  8.  Section 3.2.2: referencing RFC 8773 for PSK is incorrect. Using sole PSK 
is defined in RFC 8446, while RFC 8773 defines using PSK+Certificate.
  9.  Section 5.1: Perhaps it's worth to replace the reference to RFC 9325 here 
with the reference to BCP 195. Thus all its future versions will be accounted.
  10. Section 5.1.1. The last para is confusing. First, TLS 1.3 does not have 
cipher suites with NULL algorithms. Then, server authentication is always 
mandatory in TLS 1.3 and this document requires mutual authentication. So, it 
is not clear under what conditions this recommendation can be applied.
  11. Section 5.1.2: A naïve question - why servers MUST abruptly disconnect 
clients that send 0-RTT data instead of ignoring this data?

[Med] The authors made that change to address a comment for the secdir review. 
Since 0-RTT is not allowed (no profile is defined), I think the point was to be 
strict when clients don't follow the MUST NOT early data.


  1.  Section 5.1.3: RFC 7525 is obsoleted by RFC 9325, why it is referenced 
(along with 9325)?
  2.  Section 5.1.5: Perhaps it's worth to provide an informative reference to 
draft-ietf-tls-esni.

[Med] Beside the reference, I'm not sure ESNI is actually needed for TACACS+, 
but this is a point to clarify as well.


  1.  Sections 5.1.4, 5.1.5, 5.2, 5.3, 6.2: I think that RFC 2119 language 
should be used very carefully here. In particular, requirements to operators 
and implementations are not relevant to the protocol behavior. I think that 
low-case words "must", "should", "may" etc. should be used instead in these 
cases.
  2.  Section 6: Shouldn't the name of the section be "Operational 
Considerations"?

Regards,
Valery.

Re-,

Thank you for the positive feedback.

Mid may is OK.

Cheers,
Med

De : Valery Smyslov mailto:s...@elvis.ru>>
Envoyé : jeudi 25 avril 2024 13:05
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : 
draft-ietf-opsawg-tacacs-tl...@ietf.org
Objet : RE: Request to review draft-ietf-opsawg-tacacs-tls13

Hi Med,

I'm on vacation now till the end of April and then we'll have here few
long holidays (1st May, Victory Day), so I think I'll be able to review
the draft by the mid of May. Is it OK?

Regards,
Valery.

Hi Valery,

I hope you are doing well.

Can you please review this document (draft-ietf-opsawg-tacacs-tls13-07 - 
TACACS+ TLS 
1.3) and 
share co

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

2024-05-17 Thread mohamed . boucadair

Hi all, 

This version mirrors some of the comments raised against the UDP spec 
(ExID-related IEs). It also integrates some comments from Paul and Mahesh. 

Please check and let me know if any change is still needed. Thanks.

Cheers,
Med

> -Message d'origine-
> De : internet-dra...@ietf.org 
> Envoyé : vendredi 17 mai 2024 11:21
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : [OPSAWG]I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-
> 13.txt
> 
> 
> Internet-Draft draft-ietf-opsawg-ipfix-tcpo-v6eh-13.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-13.txt
>Pages:   24
>Dates:   2024-05-17
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-tcpo-
> v6eh%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C93cf51535
> 1f943c98ac108dc7652c48c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C638515345064539151%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sda
> ta=w%2FVSROFYwtO6dxBQxvu87etFJLKmcim8nLkuy%2FwEtDw%3D&reserved=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ipfix-tcpo-v6eh-
> 13.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C93cf51535
> 1f943c98ac108dc7652c48c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C638515345064547488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sda
> ta=QYwiJrffxfP1Q8WlAg6KNgJxPoVPMLQPTBxkHDkH9qY%3D&reserved=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-ipfix-
> tcpo-v6eh-
> 13&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C93cf515351f943
> c98ac108dc7652c48c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38515345064551870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=2j
> EtiYOiBP58hIBa0SBtN3uHDcjeQP1U6g0TkeEW15k%3D&reserved=0
> 
> 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

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: Security directorate review of draft-ietf-opsawg-ipfix-fixes-09

Hi Hilarie, 

(ccing OPSAWG)

Thank you. The review will be ACKed in the next iteration.

Cheers,
Med

> -Message d'origine-
> De : Hilarie Orman 
> Envoyé : lundi 20 mai 2024 06:49
> À : i...@ietf.org; sec...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-fixes@ietf.org
> Objet : Security directorate review of draft-ietf-opsawg-ipfix-
> fixes-09
> 
> 
>Security review of
>  Simple Fixes to the IP Flow Information Export (IPFIX) IANA
> Registry
>  draft-ietf-opsawg-ipfix-fixes-09
> 
> Do not be alarmed.  I generated this review of this document as
> part of the security directorate's ongoing effort to review all
> IETF documents being processed by the IESG.  These comments were
> written with the intent of improving security requirements and
> considerations in IETF drafts.  Comments not addressed in last
> call may be included in AD reviews during the IESG review.
> Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> 
>"When OPSAWG was considering [RFC9565] which updates
> [RFC7125], the WG
>realized that some parts of the IANA IP Flow Information
> Export
>(IPFIX) registry [IANA-IPFIX] were not up-to-date.  This
> document
>intends to update the IANA registry and bring some consistency
> among
>the entries of the registry."
> 
> This is a straightforward document that updates each information
> element, adding missing information or coreedting inconsistent
> information, as necessary.  For example, to the list of protocols
> having a source port identifier in the transport header.
> 
> No security issues are evident to me.
> 
> Hilarie

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: [Last-Call] Intdir last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08

Hi Joe,

Great. Thank you.

Cheers,
Med

De : to...@strayalpha.com
Envoyé : vendredi 17 mai 2024 23:14
À : BOUCADAIR Mohamed INNOV/NET
Objet : Re: [Last-Call] Intdir last call review of
draft-ietf-opsawg-tsvwg-udp-ipfix-08

AOK - all set.

Joe

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

On May 17, 2024, at 12:15 PM,
mohamed.boucad...@orange.com wrote:

Re-,

Thanks, Joe.

The TCP one is also in the IANA list. Please
seehttps://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-13#name-ipfix-information-element-d.

Cheers,
Med

De : to...@strayalpha.com
mailto:to...@strayalpha.com>>
Envoyé : vendredi 17 mai 2024 21:04
À : BOUCADAIR Mohamed INNOV/NET
mailto:mohamed.boucad...@orange.com>>
Objet : Re: [Last-Call] Intdir last call review of
draft-ietf-opsawg-tsvwg-udp-ipfix-08

PS - I wasn’t getting the -10 version for some reason. I am now.

I now see a valid definition in both docs.

The TCP one (U256) needs to be added to the IANA list, though.

Joe

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

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: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt: 9525 Section

t de Douglas Gash (dcmgash)
Envoyé : mercredi 20 mars 2024 16:40
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : John Heasley mailto:h...@shrubbery.net>>; Andrej Ota 
mailto:and...@ota.si>>
Objet : Re: [OPSAWG] New Version Notification for 
draft-ietf-opsawg-tacacs-tls13-06.txt

Dear OPSAWG,

We have uploaded a new version of the doc, primarily to address as much as 
possible of the comprehensive review kindly submitted by Mohamed Boucadair. We 
thank Mohamed for the time and trouble taken to the review the doc so 
thoroughly. We will be happy to discuss further any omissions or new comments 
and rectify quickly.

And we will endeavour to respond ASAP to any other comments of any kind on the 
doc.

Many thanks,

Regards,

The Authors.

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Date: Wednesday, 20 March 2024 at 15:27
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, Andrej 
Ota mailto:and...@ota.si>>, John Heasley 
mailto:h...@shrubbery.net>>, Thorsten Dahm 
mailto:thorsten.d...@gmail.com>>
Subject: New Version Notification for draft-ietf-opsawg-tacacs-tls13-06.txt
A new version of Internet-Draft draft-ietf-opsawg-tacacs-tls13-06.txt has been
successfully submitted by Douglas C. Medway Gash and posted to the
IETF repository.

Name: draft-ietf-opsawg-tacacs-tls13
Revision: 06
Title:TACACS+ TLS 1.3
Date: 2024-03-20
Group:opsawg
Pages:15
URL:  https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/
HTML: https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-06.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-tls13
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-06

Abstract:

   The Terminal Access Controller Access-Control System Plus (TACACS+)
   Protocol [RFC8907] 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 and obsoletes former inferior security
   mechanisms.



The IETF Secretariat



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.



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.

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 
infor

[OPSAWG]Re: New Version Notification for draft-ietf-opsawg-tacacs-tls13-09.txt

Hi Doug, all,

Thank you for preparing this update.

Please find below minor items that you may fix before or after the WGLC. Fixing 
them before would be my preference, though :-)

* Header

OLD: Updates: RFC8907 (if approved)
OLD: Updates: 8907 (if approved)

* Title

OLD: TACACS+ over TLS 1.3
NEW: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 
1.3

* Section 3: Redundant normative language

CURRENT: option for MD5 obfuscation, and specifies that TLS 1.3 MUST be used

and

CURRENT: TLS 1.3 [RFC8446] MUST be used for transport,

I suggest to revert back the first one.

* Section 3.2: nit

OLD: Single Connection Mode Section 4.3 of [RFC8907]
NEW: Single Connection Mode (Section 4.3 of [RFC8907])

* Section 3.2.1:

(1) nit

OLD:
   Implementations MUST support the TLS 1.3 mandatory cipher suites (TLS
   1.3 [RFC8446] Section 9.1).

NEW:

   Implementations MUST support the TLS 1.3 mandatory cipher suites (Section 
9.1 of

   [RFC8446]).

(2) consistency: the text already says that it inherits the TLS1.3 MTI, which 
is a reco.

OLD:

   This document makes no cipher suite recommendations, please refer to

   [BCP195] for guidance.

NEW:

   This document makes no additional cipher suite recommendations. Readers 
should refer to

   [BCP195] for guidance.


* Section 3.2.2: normative language

OLD: Unless disabled by configuration, a peer MUST not permit connection
NEW: Unless disabled by configuration, a peer MUST NOT permit connection

* Section 3.2.2.1: nit

OLD: revocation must be handled as it is not part of the standard. .
NEW: revocation must be handled as it is not part of the standard.

* Section 5.1.1: expand on why 3365 readers should look at 3365.

CURRENT:

   It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication

   and encryption, unless within test and debug environments.  Also see

   [RFC3365].

* Section 5.1.3: readability

OLD:
   Also useful are TLS 1.3 specifications themselves (TLS 1.3
   [RFC8446]), which prescribes mandatory support in Section 9.

NEW:
   Also, Section 9 of [RFC8446] prescribes mandatory support in Section 9.

I'm tempted to simply delete that text given the discussion in 3.2.1.

* Section 8: Please list Tiru and Valery reviews. Thanks.

* Section 9:


(1) Move FIPS-140-3 to be listed as informative.

(2) Delete this entry as it is not cited in the text




   [RFC7605]  Touch, J., "Recommendations on Using Assigned Transport

  Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,

  August 2015, https://www.rfc-editor.org/info/rfc7605.

Cheers,
Med

De : Douglas Gash (dcmgash) 
Envoyé : mardi 21 mai 2024 19:03
À : opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET 
; tirumal reddy ; Valery 
Smyslov (s...@elvis.ru) 
Cc : Andrej Ota ; John Heasley ; Thorsten 
Dahm 
Objet : Re: New Version Notification for draft-ietf-opsawg-tacacs-tls13-09.txt


Dear OPSAWG et al,

We have uploaded a version with initial responses to the reviews and insights 
kindly provided by Tirumal and Valery, and will be happy to make good any 
omissions or needed corrections ASAP.

Many thanks,

The Authors.

From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Date: Tuesday, 21 May 2024 at 17:57
To: Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, 
Douglas Gash (dcmgash) mailto:dcmg...@cisco.com>>, Andrej 
Ota mailto:and...@ota.si>>, John Heasley 
mailto:h...@shrubbery.net>>, Thorsten Dahm 
mailto:thorsten.d...@gmail.com>>
Subject: New Version Notification for draft-ietf-opsawg-tacacs-tls13-09.txt
A new version of Internet-Draft draft-ietf-opsawg-tacacs-tls13-09.txt has been
successfully submitted by Douglas C. Medway Gash and posted to the
IETF repository.

Name: draft-ietf-opsawg-tacacs-tls13
Revision: 09
Title:TACACS+ over TLS 1.3
Date: 2024-05-21
Group:opsawg
Pages:15
URL:  https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-09.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/
HTML: https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-09.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-tls13
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-09

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 Secretariat

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans auto

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

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]Re: Opsdir last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-10