Subject: [Dots] Data Channel Fragment handling nits

From: "Jon Shallow" <[email-masked]>
Date: Tue, 15 May 2018 13:47:06 +0100

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.

The YANG bits type conversions to JSON in the Appendix A are wrong - I
initiated this error.

                     "flags": {

                       "more": 1

                     }

Should be 

                     "flags": { "more"}

And

                     "flags": {

                       "more": 0

                     }

Should be 

                     "flags": { ""}

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 15 May 2018 13:20:27 +0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : mardi 15 mai 2018 14:47
À : [email-masked]
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.

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

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 15 May 2018 14:52:29 +0100

Hi Med,

See inline.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 15 May 2018 14:20
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Data Channel Fragment handling nits

Hi Jon, 

Please see inline. 

Cheers,

Med

Hi there,

[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.  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)?
~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

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 15 May 2018 21:06:32 +0700

On 15 May 2018, at 20:52, Jon Shallow wrote:

> do we actually need both v4-fragment and v6-fragment

We need support for non-initial fragments on both IPv4 and IPv6, yes.

> and just use fragment (in the same way that length is common)?

If that can be made to work for both, sure.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: <[email-masked]>
Date: Tue, 15 May 2018 14:13:49 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 15 mai 2018 15:52
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] Data Channel Fragment handling nits

Hi Med,

See inline.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 15 May 2018 14:20
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data Channel Fragment handling nits

Hi Jon,

Please see inline.

Cheers,
Med

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

Hi there,

[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"
       },

~Jon

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

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

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 15 May 2018 15:48:05 +0100

Hi there

See inline [Jon1]

Regards

Jon

Hi there,

[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: 

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

         "source-prefix": "true",

         "fragment": "true"

       },

       "ipv6": {

         "length": "true",

         "protocol": "true",

         "source-prefix": "true",

         "fragment": "true"

       },

[Jon1] Works for me
~Jon1
~Jon

[Med] Good catch. Fixed. 

                     "flags": {

                       "more": 1

                     }

Should be 

                     "flags": { “more”}

And

                     "flags": {

                       "more": 0

                     }

Should be 

                     "flags": { “”}

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 18 May 2018 07:13:29 +0000

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, May 15, 2018 8:18 PM
To: [email-masked]; [email-masked]
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

Hi there,

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

       "ipv4": {
         "length": "true",
         "protocol": "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