The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'An Update to
the tcpControlBits IP Flow Information Export (IPFIX)
Information Element'
as Proposed Standard
The IESG plans to make a decision in the
On Thu, 12 Oct 2023 at 18:05, wrote:
> Thank you for catching this.
>
>
>
> What is actually interesting is that we are discussing a PR to make the
> change in the other way around:
> https://github.com/boucadair/policy-based-network-acl/pull/20/files.
>
The PR documents the length of group-id
Hi Thomas,
thank you for your feedback.
I have a couple of comments.
In section 6.1 for IPFIX, in order to calculate loss you said to use for
packets the entity octetDeltaCount(IE1). But might it be better to use the
entity packetDeltaCount(IE2)?
Moreover I suggest for the delay to add the use
Hi Heikki,
Thank you for catching this.
What is actually interesting is that we are discussing a PR to make the change
in the other way around:
https://github.com/boucadair/policy-based-network-acl/pull/20/files.
Cheers,
Med
De : radext De la part de Heikki Vatiainen
Envoyé : jeudi 12
On Tue, 26 Sept 2023 at 15:01, wrote:
> Hi RADEXT,
>
>
>
> FWIW, the document specifies the following new RADIUS attribute:
>
>
> https://boucadair.github.io/policy-based-network-acl/draft-ietf-opsawg-ucl-acl.html#name-user-access-control-group-i
>
Hello Med,
the example tables in the draft
Internet-Draft draft-ietf-opsawg-rfc7125-update-05.txt is now available. It is
a work item of the Operations and Management Area Working Group (OPSAWG) WG of
the IETF.
Title: An Update to the tcpControlBits IP Flow Information Export (IPFIX)
Information Element
Author: Mohamed Boucadair
Hi Med,
I think this is pretty much good to go except for some funny line wrapping and
indentation. It is probably worth fixing that in a -05 and then I'll kick off
IETF LC.
I.e.
Note also that [TCP-FLAGS] indexes the bit offset from the
most-significant
bit of octet 12
Thanks, Qiufang. Olga asked the question, as I recall. Your answer here makes
sense, and I would emphasize this in the document to be clear what hardware
ramifications might exist and what operational tradeoffs one would consider.
Joe
From: maqiufang (A)
Date: Thursday, October 12, 2023 at
Hi Joe, all,
I support the adoption of the four drafts. These four drafts are a good
supplement to the existing VPN and IETF Network Slice service models.
Decoupling ACs from service models improves service deployment flexibility. And
the network slice service model has already added
Hi Rob,
Thanks for the follow up.
Looks good to me. This is now fixed in draft-ietf-opsawg-rfc7125-update-04
which is available online.
Thanks.
Cheers,
Med
> -Message d'origine-
> De : Rob Wilton (rwilton)
> Envoyé : jeudi 12 octobre 2023 12:53
> À : BOUCADAIR Mohamed INNOV/NET ;
Hi, Luis
Thanks a lot for sharing your viewpoints!
Yes, it is possible that the user/device could be defined as pertaining to more
than one group, depending on the current context. The example that has been
given in the draft is that, the user group R Regular and R BYOD may share
the same set
Internet-Draft draft-ietf-opsawg-rfc7125-update-04.txt is now available. It is
a work item of the Operations and Management Area Working Group (OPSAWG) WG of
the IETF.
Title: An Update to the tcpControlBits IP Flow Information Export (IPFIX)
Information Element
Author: Mohamed Boucadair
Hi Med,
I still think that there needs to be a more explicit statement. E.g., the
description of the tcpControlBits talks about setting it to one if the bit is
set, and then references the "TCP Header Flags". So I think that you should
add something like the following:
"Note, the TCP-FLAGs
Hi, Adrian
Thanks a lot for the comments! The authors have create a PR to resolve these:
https://github.com/boucadair/policy-based-network-acl/pull/19/files, except the
one that moves the schedule model in a separate draft, we have created an issue
to track this alone:
Hi, Joe
Apologize for being late with this response.
Please first allow me to give more context about this specific question, I
recall presenting the next step of this work in IETF 117, to add
application-group as the third endpoint group (beside user-group and
device-group), the authors
15 matches
Mail list logo
