Re: [6lo] 6lo Last Call: draft-ietf-6lo-dispatch-iana-registry

[Samita Chakrabarti <[e-mail]>]

Acknowledged. Will do the change.
-Samita

-----Original Message-----
From: Gabriel Montenegro [mailto:[e-mail]] 
Sent: Saturday, March 19, 2016 5:07 PM
To: Pascal Thubert (pthubert); Samita Chakrabarti; Brian Haberman; [e-mail]
Cc: Jonathan Hui
Subject: RE: [6lo] 6lo Last Call: draft-ietf-6lo-dispatch-iana-registry

+1 on Pascal's point, I also don't see the need for the complexity.

I'd rather we change SHOULD to MUST place ESC before IP packet. 

> -----Original Message-----
> From: 6lo [mailto:[e-mail]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Saturday, March 19, 2016 02:40
> To: Samita Chakrabarti <[e-mail]>; Brian 
> Haberman <[e-mail]>; [e-mail]
> Cc: Jonathan Hui <[e-mail]>
> Subject: Re: [6lo] 6lo Last Call: 
> draft-ietf-6lo-dispatch-iana-registry
> 
> Hello Samita:
> 
> I'm perfectly happy with this, but for point 1.
> 
> RFC 6282 has "The IPv6 Payload Length field MUST always be elided and 
> inferred from lower layers using the 6LoWPAN Fragmentation header or 
> the IEEE 802.15.4 header." This denotes the assumption that the length 
> of all that is not IP is in the frame known, and that IP and its 
> payload is the rest of the frame. Current Implementations are expected 
> to consider that the rest of the frame after the IPHC is the rest of 
> the IP packet and it would be better that we stay backward compatible 
> with that. Otherwise 6LoWPAN may end up injecting data at the end of 
> the packets that the transport and security layers may or may not process correctly.
> 
> In any fashion, if we allowed esc after IPHC, then I'm unclear how an 
> implementation will figure the end of the IPv6 payload. It is valid to 
> have a byte in IP payload with the same value as esc so an 
> implementation cannot just scan the data. Should it have to look into the transport?
> 
> Now I'm wondering if there is a need for this complexity? Do we have 
> actual use cases where esc would be after the IP packet?
> 
> Take care,
> 
> Pascal
> 
> 
> > -----Original Message-----
> > From: Samita Chakrabarti [mailto:[e-mail]]
> > Sent: samedi 19 mars 2016 02:21
> > To: Pascal Thubert (pthubert) <[e-mail]>; Brian Haberman 
> > <[e-mail]>; [e-mail]
> > Cc: Jonathan Hui <[e-mail]>
> > Subject: RE: [6lo] 6lo Last Call:
> > draft-ietf-6lo-dispatch-iana-registry
> >
> > Hi Pascal,
> >
> >
> > Thanks so much for the detail review and the good catch on 
> > fragmentation and sequence after LOWPAN_IPHC.
> > Please see our response in-line and proposed updates.
> >
> > -----Original Message-----
> > From: 6lo [mailto:[e-mail]] On Behalf Of Pascal Thubert
> > (pthubert)
> > Sent: Tuesday, March 08, 2016 7:52 AM
> > To: Brian Haberman; [e-mail]
> > Cc: Jonathan Hui
> > Subject: Re: [6lo] 6lo Last Call:
> > draft-ietf-6lo-dispatch-iana-registry
> >
> > Hello Brian:
> >
> > Sorry for this delay, please find some comments below:
> >
> > 1) Sections 3 and 3.2 provide an example whereby the esc sequence is 
> > used after the IPHC+IP payload. One issue with that is that the 
> > packet length is elided by RFC6282 (section 3.2) and assumes the 
> > rest of the frame. If the ESC can be placed after an IPHC then we 
> > need to signal the size of the IP payload. An alternate approach 
> > would be that the order is enforced indicating that the escaped data 
> > is always before the IP
> header.
> >
> > [SC>]
> >
> > Good catch.  Though RFC8262 is not very clear that IPHC payload 
> > means the rest of the frame. But due to not being clear we could 
> > have implementations which can assume so. In order to mitigate this 
> > problem, we propose the updated text as following:
> >
> > ====
> > 3.2.  ESC Extension Bytes Typical Sequence
> >
> > When LOWPAN_IPHC is present, the ESC bytes SHOULD  appear before 
> > LOWPAN_IPHC dispatch type. But if the implementation requires ESC 
> > byte to be placed after LOWPAN_IPHC dispatch and payload, then the 
> > elided IPHC payload length MUST include the ESC bytes. It means  
> > during de-capsulation of ESC bytes the LOWPAN_IPHC payload length  
> > need to be adjusted [RFC
> > 6282 section 3.2] ==========
> >
> >
> > 2) Section 3 says 'as long as it ... does noy induce fragmentation.'
> > I'm unsure why 6LoWPAN fragmentation would be incompatible with the 
> > use
> of escape?
> > [SC>]  That will be addressed by the above change.
> >
> > 3) Section 3.1 mandates that unknown EEDs are dropped. This is a 
> > regression from IPv6 options which can signal whether they can be 
> > skipped,
> and 6LoRH.
> > An alternate approach that is compatible with ITU-T specs could be 
> > to use the most (2? 3?) significant bits set to indicate skippable, 
> > in which case the other 7 (6?, 5?) bits could be a length in bytes, 
> > and then the next octet would be an EED. This would give us 127 
> > (191?,
> > 223?) non skippable EEDs and 254 skippable EEDs.
> > [SC>]
> > [SC>]  We don't agree that it is a regression from IPv6 options.
> > These are ESC bytes not IPv6 options.
> > The idea of separating this document vs the 6loh and 6lorh-paging 
> > document are that we want to keep the definition and usage of ESC 
> > bytes simple. If there is a need for skip-able ESC bytes sequence, 
> > then that can be introduced in some other document (ex. 6loRH ? ) 
> > where the application demands it.
> >
> > So our conclusion is to keep it simple and drop unknown ESC bytes.
> >
> >
> > 4) Section 3.4 does not update RFC4944 on NALP. Since NALP denotes a
> > non- 6LoWPAN behavior, it could be clarified that NALP is not 
> > expected inside a 6LoWPAN frame, meaning after a 6LoWPAN dispatch was found.
> > After a transition phase, this would reopen the 00xxxxxx dispatch 
> > space inside a 6LoWPAN frame.
> >
> > -
> > [SC>]  We worked on a new text to clarify difference between ESC and 
> > NALP bytes as we see today.
> >
> > ===========
> > 3.4 NALP and ESC bytes
> >
> >
> > According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are 
> > reserved in order to identify  non-6lowpan payloads.
> > This is another approach of an escape method for a 6lowpan 
> > implementation and the handling NALP frame is clarified in [RFC4944].
> >
> > This document clarifies that NALP dispatch codes only provides an 
> > escape method for non-6LoWPAN payloads when they appear as the 
> > initial byte of a LoWPAN encapsulation, and that the potential 
> > meaning of their appearance in any other location is reserved for future use.
> >
> > Since ESC bytes are extended  6lowpan dispatch types, they are 
> > orthogonal to NALP bytes.
> >
> > ====
> >
> >
> > -Samita and co-authors
> >
> >
> > > -----Original Message-----
> > > From: 6lo [mailto:[e-mail]] On Behalf Of Brian 
> > > Haberman
> > > Sent: mardi 1 mars 2016 16:24
> > > To: [e-mail]
> > > Cc: Jonathan Hui <[e-mail]>
> > > Subject: [6lo] 6lo Last Call:
> > >
> > > All,
> > >      This message starts a 2-week working group last call on advancing:
> > >
> > >      Title      : IANA Registry for 6lowpan ESC Dispatch Code points
> > >      Authors    : Samita Chakrabarti
> > >                   Gabriel Montenegro
> > >                   Ralph Droms
> > >                   James Woodyatt
> > >      Filename   : draft-ietf-6lo-dispatch-iana-registry-01.txt
> > >      Pages      : 8
> > >      Date       : 2016-02-25
> > >
> > > as a Proposed Standard. All substantive comments are to be posted 
> > > to the mailing list. Editorial comments should be sent to the 
> > > document
> > authors.
> > > This last call will end on 2016-03-15.
> > >
> > > Regards,
> > > Brian
> >
> > _______________________________________________
> > 6lo mailing list
> > [e-mail]
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
> > .i
> >
> etf.org%2fmailman%2flistinfo%2f6lo&data=01%7c01%7cGabriel.Montenegro
> %4
> >
> 0microsoft.com%7c7710e598250247242ac808d34fdab0b8%7c72f988bf86f14
> 1af91
> >
> ab2d7cd011db47%7c1&sdata=TU%2fKAzUVEIvEyFurkHDW7hMqRK6wYl8q2x3
> cTmIsrdU
> > %3d
> 
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.
> org%2fmailman%2flistinfo%2f6lo&data=01%7c01%7cGabriel.Montenegro%40
> microsoft.com%7c7710e598250247242ac808d34fdab0b8%7c72f988bf86f141
> af91ab2d7cd011db47%7c1&sdata=TU%2fKAzUVEIvEyFurkHDW7hMqRK6wYl8
> q2x3cTmIsrdU%3d