Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a decode function to convert.py for MAC, IPs, and numeric values. #589

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Abhinavcode13
Copy link
Contributor

  • Added decode function can decode various types of encoded values.

@jafingerhut
Copy link
Collaborator

I withdraw (and deleted) my previous comment. If you happen to see it in email, you can ignore it.

Is there a example use case you expect where this new decode function would be used?

@Abhinavcode13
Copy link
Contributor Author

Abhinavcode13 commented Apr 16, 2024

I withdraw (and deleted) my previous comment. If you happen to see it in email, you can ignore it.

Is there a example use case you expect where this new decode function would be used?

@jafingerhut

The main reason for including this decode function is as follows:

  • It may be challenging to decode the values in the match fields of an already-running device as we won't be aware of the kind of entries it currently has in its table.
  • Adding a more general decode function to convert.py that determines whether the value is a numeric, MAC, or IP value and then interprets the decode result appropriately.

@jafingerhut
Copy link
Collaborator

So the thing that seems strange to me about this new function is that you give it a byte string, with presumably no knowledge whatsoever of what that byte string is intended to represent. This new decode function assumes it is either an IPv6 address, an IPv4 address, or a MAC address, and opportunistically tries to decode it to a human-readable string representing that address, even if the byte string is just some other 128-, 32-, or 48-bit value that has nothing to do with one of those address types. It seems difficult for me to imagine when one would find that useful. At least with the existing decodeIPv4, decodeIPv6, and decodeMac, the caller knows that the byte string is supposed to represent an address of the given kind, and tries to decode it with that assumption.

@Abhinavcode13
Copy link
Contributor Author

Thank you for pointing that out! I'll revisit my implementation for this decode function to ensure it aligns with the intended use case.

@Abhinavcode13 Abhinavcode13 marked this pull request as draft April 19, 2024 15:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants