Re: [Dots] Data Channel Fragment handling nits

["Konda, Tirumaleswar Reddy" <[e-mail]>]

From: Dots [mailto:[e-mail]] On Behalf Of Jon Shallow
Sent: Tuesday, May 15, 2018 8:18 PM
To: [e-mail]; [e-mail]
Subject: Re: [Dots] Data Channel Fragment handling nits


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi there

See inline [Jon1]

Regards

Jon

De : Dots [mailto:[e-mail]] De la part de Jon Shallow
Envoyé : mardi 15 mai 2018 14:47
À : [e-mail]<mailto:[e-mail]>
Objet : [Dots] Data Channel Fragment handling nits

Hi there,

I am beginning to with that I had not raised how to handle fragments, but it was keyed off my naive interpretation of the handling of IPv6 protocols by netmod-acl!

Making this changes has raised some inconsistencies in the draft data channel document.
Searching on fragment reveals v4-fragment and v6-fragment which are no longer used.


[Med] Hmm. These are related to the capabilities of a DOTS server to enforce fragment-based filtering. See Figure 23 for an example.

[Jon] I agree – Hmm.

[Med] Cool.



  However the v4-fragment is alluding to “flags” being supported and v6-fragment to “fragment” being supported – not that intuitive!  They really should be an identical name match.  There is a part of me that would like to go back to as it was now that we know that we have to support “fragment” for IPv6 no matter what; unless netmod-acl comes up with something sensible (unlikely).  If we do go back, then do we actually need both v4-fragment and v6-fragment and just use fragment (in the same way that length is common)?



[Med] The use of the same name as part of the capabilities is possible only if we have distinct containers; each for address family (IPv4, IPv6). In the current version, we tried to have something compact:


       "fragment": ["v4-fragment", "v6-fragment"]


We may include a fragment leaf as part of ipv4 and ipv6 containers and then use the same name. Then, it will look like:


       "ipv4": {
         "length": "true",
         "protocol": "true",
         "destination-prefix": "true",
         "source-prefix": "true",
         "fragment": "true"
       },
       "ipv6": {
         "length": "true",
         "protocol": "true",
         "destination-prefix": "true",
         "source-prefix": "true",
         "fragment": "true"
       },



[Jon1] Works for me



[TR] Looks good to me .



Cheers,

-Tiru



~Jon1

~Jon

The YANG bits type conversions to JSON in the Appendix A are wrong – I initiated this error.
[Med] Good catch. Fixed.

                     "flags": {
                       "more": 1
                     }
Should be
                     "flags": { “more”}

And
                     "flags": {
                       "more": 0
                     }
Should be
                     "flags": { “”}


Regards

Jon