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

[Carlos Pignataro]

Dear Greg,

Thank you for your interest in our draft, and the associated extensive
comments! All welcome!

*CMP: Please find some additional follow-ups.*

On Sat, Jan 13, 2024 at 7:52 PM Greg Mirsky  wrote:

> Hi Adrian,
> thank you for your kind consideration of my notes. Please find my
> follow-up notes below tagged by GIM>>.
>
> Regards,
> Greg
>
> On Fri, Jan 12, 2024 at 11:25 AM Adrian Farrel 
> wrote:
>
>> Hi Greg,
>>
>>
>>
>> Thanks for your thoughtful inspection of our draft.
>>
>>
>>
>> Carlos and I wanted to be sure that all of the discussions of this draft
>> were indexed on one list, and we wanted to avoid multiple copies going to
>> people who are subscribed to multiple lists. So we asked that follow-ups
>> went only to OPSAWG. I have moved IPPM, MPLS, SPRING, and DetNet to BCC on
>> this email.
>>
> GIM>> Thank you.
>
>>
>>
>> It was certainly not our intent to disparage any work that was being done
>> in any other working group, and I understand the effort that has gone into
>> the DetNet OAM Framework to ensure that the terminology is clear and
>> unencumbered in the DetNet context.
>>
>>
>>
>> Our concern was, however, that different contexts are applying different
>> definitions of the terms “in-band” and “out-of-band”. Those definitions are
>> (often) clear and precise, but they are not consistent across contexts.
>> Thus, a water-tight definition in the DetNet context is not universally
>> applicable, and a reader coming to DetNet from another context may bring
>> with them their own understanding of the terms.
>>
> GIM>> Although the wording in the DetNet OAM Framework is indeed specific
> for DetNet environment, for example, the reference to DetNet service
> sub-layer and PREOF, the authors and the WG strived to make the definitions
> generic. I believe that we achieved a reasonable level of generality
> because the interpretation of "in-band/out-of-band" terminology in RAW OAM
> was based on our work in DetNet. I believe that it could be a reasonable
> way of building common understanding through a discussion of existing terms
> instead of fork-lifting and trying to invent something different that has
> not been used by any WG.
>

CMP: The set of challenges continues to be that
*(1) these are still context-dependent re-definitions of
"in-band". draft-ietf-detnet-oam-framework says "*In-band OAM is [...]
within the monitored DetNet OAM domain [... long set of conditions ...]*".
Clearly, these are only within a DetNet context. These are not portable nor
generic or generalizable.*
*(2) the terms "in-band"/"out-of-band" are already tainted with a multitude
of potential meanings, and have interpretations attached to them. *
*(3) IOAM saw the same confusion with the I for "in-band", and instead of
redefining it with a narrower scope, it changed the term to a finer
resolution of the defintion and uniqueness (there is no band)*
CMP: Thus far, this does not show to me that the terms are confusion-safe.



>
>>
>> Our intent, therefore, is to select a finer-grained set of terms that
>> have universal applicability and that can be selected within a context
>> without loss of generality.
>>
> GIM>> I agree with that wholeheartedly.
>
>>
>>
>> This is a tricky little subject and I know that Carlos and I expected it
>> to generate more than a little discussion. If we end up with “everything is
>> OK and nothing needs to change” that will be OK with us. If we discover
>> that some work is using terms too generally, while others already have
>> perfect definitions, that will lead to something similar to this document
>> to bring the good into the light.
>>
>>
>>
>> Further comments in line…
>>
>>
>>
>>
>>
>> *From:* Greg Mirsky 
>> *Sent:* 12 January 2024 00:09
>> *To:* Carlos Pignataro ; Adrian Farrel <
>> adr...@olddog.co.uk>
>> *Cc:* Ops Area WG ; IETF IPPM WG ; mpls <
>> m...@ietf.org>; spring ; DetNet WG 
>> *Subject:* Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"
>>
>>
>>
>>- Hi Carlos and Adrian,
>>
>> thank you for starting this work. I believe that having a common
>> dictionary helps in having more productive discussions. I took the liberty
>> of inviting all the WGs which you invited to review the document and added
>> DetNet WG. Please feel free to trim the distribution list.
>>
>> I've read the document and have several general questions to start our
>> discussion:
>>
>>- It seems that the motivation of this document is the assumption
>>that "in-band OAM" and "out-of-band OAM" are not representative or cannot
>>be understood or correctly attributed, interpreted by the IETF community.
>>Is that correct?
>>
>> I think the wording here would be “cannot be reliably understood
>> consistently”. That is, without looking at a context-specific definition
>> (such as that which you supply in the DetNet OAM Framework), the use of the
>> terms may be misinterpreted.
>>
>> This is an assertion, but one (we think) is founded on observation of
>> recent conversations 

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

[Wesley Eddy]

On 1/16/2024 11:10 AM, mohamed.boucad...@orange.com wrote:


Are you expecting the implementation to have an exhaustive list of all 
of the ExIDs in use to understand the difference between 2 and 4 byte 
usage?


*/[Med] Yes because otherwise an implem can’t unambiguously identify 
and extract ExIDs. We do provide a pointer to the registered ExIDs:/*


*//*

*/==/*

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

*/== /*

*//*

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


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




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

Re: [OPSAWG] [Int-dir] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

[to...@strayalpha.com]

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

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

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

Joe

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

> On Jan 16, 2024, at 12:28 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Joe,
>  
> Thanks for the follow-up.
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> De : to...@strayalpha.com   > 
> Envoyé : lundi 15 janvier 2024 17:17
> À : BOUCADAIR Mohamed INNOV/NET  >
> Cc : int-...@ietf.org ; 
> draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org 
> ; opsawg@ietf.org 
> 
> Objet : Re: Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03
>  
> Please see below.
>  
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com 
> 
> 
> On Jan 15, 2024, at 12:26 AM, mohamed.boucad...@orange.com 
>  wrote:
>  
> Hi Joe, 
> 
> Thanks for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> 
> -Message d'origine-
> De : Joseph Touch via Datatracker mailto:nore...@ietf.org>>
> Envoyé : samedi 13 janvier 2024 05:03
> À : int-...@ietf.org 
> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org 
> ;
> opsawg@ietf.org 
> Objet : Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-
> 03
> 
> Reviewer: Joseph Touch
> Review result: Ready with Issues
> 
> This review is performed as part of the INTAREA cross-area
> review.
> 
> There do not appear to be any INTAREA issues in this document.
> 
> NOTE: as author of the UDP options on which this document is
> based, I have some other concerns noted below, which are the
> "issues" indicated in the review result (ready with issues).
> 
> There are some misconceptions about UDP options that should be
> corrected in this document:
> 
> Regarding SAFE options:
> -   “Such options can be silently ignored by receivers
> without affecting
> the meaning of the UDP user data” -   Should be “Such options
> can be
> silently ignored by legacy receivers because they do not alter
> the UDP user data”
> 
> Regarding UNSAFE options:
> -   “Such options are not safe to ignore”
> -   Should be “Such options are not safe tor legacy receivers
> to ignore
> because they alter the UDP user data”
> 
> 
> [Med] Fixed.
>  
> It would be useful to use a consistent phrase to describe the "UDP user data" 
> (e.g., as per your Fig 1), i.e., rather than also “UDP data payload”.
> [Med] Updated the text to use consistent wording for both safe/unsafe text.
> 
> 
> The document should be more clear that UDP options occur per-
> packet within a flow and can be introduced at any time in the
> flow (unlike TCP).
> 
> [Med] Added a new statement to echo this. The export process covers any 
> option that is observed in a flow.
> 
> 
> 
> Sec 4.1 needs to indicate use of a field with 256 possible
> values; it currently is defined for only 32 or 64 values.
> 
> 
> 
> [Med] 32/64 are provided as examples to illustrate the use of reduced 
> encoding. The full 256 range is covered in the spec. Thanks. 
>  
> “Unsigned” without numeric qualifiers is not an IPFIX data type, per RFC7011 
> Sec 6.1.1.
>  
> Sec 6.2 indicates the specific encoding types where reduced encoding applies, 
> and also uses unsigned only with numeric qualifiers.
>  
> [Med] You are right. Updated the text to use a new abstract data type defined 
> in another ongoing opsawg-ipfix spec.
>  
> Joe
>  
>  
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> 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.
> 

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

[mohamed . boucadair]

Hi Wes,

Please see inline.

Cheers,
Med

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


The changes look good to me; I just want to make sure you understand one of my 
questions that doesn't look like it was clear enough:
On 1/15/2024 4:13 AM, 
mohamed.boucad...@orange.com wrote:

- The way an implementation understands the TCP ExIDs may benefit

from slightly more explanation:

  -- In 4.2 and 4.3, is the idea that the implementation is just

sampling the

  16 or 32 bits following the experimental option kind being

indicated, and

  assuming those 2 or 4 bytes to be ExIDs?  From Section 6.2, I

got the sense

  that the implementation is aware of particular ExID values

specifically, to

  know if they should be reported as 2 or 4 byte values.

[Med] 2-byte IDs are reported in tcpSharedOptionExID16 while 4-byte IDs are 
reported in tcpSharedOptionExID32.
Are you expecting the implementation to have an exhaustive list of all of the 
ExIDs in use to understand the difference between 2 and 4 byte usage?
[Med] Yes because otherwise an implem can’t unambiguously identify and extract 
ExIDs. We do provide a pointer to the registered ExIDs:

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

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

  I don't quite understand how this is supposed to work at the sampling point, 
since it's the TCP implementation that interprets the option and determines 
whether it is to be interpreted as containing (1) no ExID, (2) a 16-bit ExID, 
(3) a 32-bit ExID.  This information is not available within the protocol to a 
third party.  The third party would need a list of ExIDs in-use in order to 
understand them.

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Wesley Eddy]

The changes look good to me; I just want to make sure you understand one 
of my questions that doesn't look like it was clear enough:


On 1/15/2024 4:13 AM, mohamed.boucad...@orange.com wrote:

- The way an implementation understands the TCP ExIDs may benefit
from slightly more explanation:
   -- In 4.2 and 4.3, is the idea that the implementation is just
sampling the
   16 or 32 bits following the experimental option kind being
indicated, and
   assuming those 2 or 4 bytes to be ExIDs?  From Section 6.2, I
got the sense
   that the implementation is aware of particular ExID values
specifically, to
   know if they should be reported as 2 or 4 byte values.

[Med] 2-byte IDs are reported in tcpSharedOptionExID16 while 4-byte IDs are 
reported in tcpSharedOptionExID32.
Are you expecting the implementation to have an exhaustive list of all 
of the ExIDs in use to understand the difference between 2 and 4 byte 
usage?  I don't quite understand how this is supposed to work at the 
sampling point, since it's the TCP implementation that interprets the 
option and determines whether it is to be interpreted as containing (1) 
no ExID, (2) a 16-bit ExID, (3) a 32-bit ExID. This information is not 
available within the protocol to a third party.  The third party would 
need a list of ExIDs in-use in order to understand them.___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[internet-drafts]

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

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

Abstract:

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

Discussion Venues

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

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

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

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

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

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

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


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

Re: [OPSAWG] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

[mohamed . boucadair]

Hi Joe,

Thanks for the follow-up.

Please see inline.

Cheers,
Med

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

Please see below.

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


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

Hi Joe,

Thanks for the review.

Please see inline.

Cheers,
Med


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

Reviewer: Joseph Touch
Review result: Ready with Issues

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

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

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

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

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

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

[Med] Fixed.

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


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

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



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


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

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

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

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

Joe



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

[mohamed . boucadair]

Hi Tommy, 

Thanks for clarifying. You have a valid point. 

Updated the type to point to unsigned256, which is now defined in 
draft-ietf-opsawg-ipfix-tcpo-v6eh.

Cheers,
Med

> -Message d'origine-
> De : Tommy Pauly 
> Envoyé : lundi 15 janvier 2024 15:06
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : tsv-...@ietf.org; draft-ietf-opsawg-tsvwg-udp-
> ipfix@ietf.org; opsawg@ietf.org
> Objet : Re: Tsvart early review of draft-ietf-opsawg-tsvwg-udp-
> ipfix-03
> 
> Hi Med,
> 
> I understand that fewer bits are needed in practice, and RFC 7011
> would allow a field defined as an unsigned64 to be sent as fewer
> bits on the wire. However, for the IANA registration, I still
> would expect this field to match the existing fields and not have
> a unique type just called “unsigned”.
> 
> Tommy
> 
> > On Jan 15, 2024, at 12:32 AM, mohamed.boucad...@orange.com
> wrote:
> >
> > Hi Tommy,
> >
> > Thank you for the review.
> >
> > The encoding should allow to export the full 256 range, but it
> is likely that fewer bits will be needed. unsigned32/unsigned64
> are provided as examples to illustrate the use of reduced
> encoding
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7011%23section-
> 6.2=05%7C02%7Cmohamed.boucadair%40orange.com%7C923c03240dcb4
> 5e404ff08dc15d33104%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638409244003749283%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> a=LZOS7V39SarOBVwo6FTdrjc8HQcv3DZdgztKHqORNWU%3D=0).
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Tommy Pauly via Datatracker  Envoyé :
> mardi 2
> >> janvier 2024 18:08 À : tsv-...@ietf.org Cc :
> >> draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org;
> >> opsawg@ietf.org
> >> Objet : Tsvart early review of draft-ietf-opsawg-tsvwg-udp-
> ipfix-
> >> 03
> >>
> >> Reviewer: Tommy Pauly
> >> Review result: Almost Ready
> >>
> >> Thanks for writing a clear and succinct draft. I only found
> one issue
> >> of note, around the registration of the new udpOptions
> Information
> >> Element.
> >>
> >> Section 4.1:
> >> The data type used for the "udpOptions" entry is just listed
> as
> >> "unsigned", and is described as being either an unsigned32 or
> an
> >> unsigned64. However, when I look at the registry at
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>
> Fwww.iana.org%2Fassignments%2Fipfix%2Fipfix.xhtml=05%7C02%7C
> >>
> mohamed.boucadair%40orange.com%7C7a23dc00f97a4cadeee208dc0bbf
> >>
> %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638398120645105476%
> >>
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> >>
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=P9pWAnW5VI1SzmRx4
> >> Q%2FB2wOa3rsve1uOdsRm%2BMNB4%2B0%3D=0, I don't see
> any
> >> entries that use this abstract "unsigned" type, and it is not
> listed
> >> as an option in the element data types. Is there a reason this
> >> shouldn't just be registered as an unsigned64? My
> understanding from
> >>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >> Fwww.rfc-editor.org%2Frfc%2Frfc7011%23section-
> >>
> 6.2=05%7C02%7Cmohamed.boucadair%40orange.com%7C7a23dc00f97a4
> >>
> cadeee208dc0bbf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> >>
> 638398120645105476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> >>
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> >> a=1FvKZv60OgONy5w%2BygO9sSnBN121J9yveL7Gkv15apI%3D=0
> is that
> >> an unsigned64 can be automatically encoded as an unsigned32 if
> the
> >> value is small enough, so the definition can just use
> unsigned64.
> >>
> >
> >
> _
> _
> > __
> > 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