Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[Robert Moskowitz <[e-mail]>]

Do you recommend I submit a -02 ver which is just the -00 (without 
Extension Header)?  That the wg would then adopt

Or wg just adopts -00 and I submit that as wg ver?

Bob


On 9/9/22 11:34, Eric Vyncke (evyncke) wrote:
> Without any hat, this proposal does not look like an extension header (i.e., it does not extend the semantic of the IP packet, it 'just' compress it) and looks more like a tunnel/transport header to me.
>
> All in all, it requires an IP protocol number
>
> -éric
>
> On 08/09/2022, 00:25, "Int-area on behalf of Joel Halpern" <[e-mail] on behalf of [e-mail]> wrote:
>
>      As far as I can tell, SCHC has the same conceptual structure as almost
>      all of our tunnel protocols.   Which we do not call extension headers.
>      Sure, they are not really upper layer protocols.  But (although not
>      described the way John Day does) we understand that "upper" can be
>      recursion at the same layer.
>
>      If we declare SCHC to be an extension header, I do not know how we
>      answer the question the next time someone asks us "is this use an upper
>      layer header or an extension header?"  As long as we provide an ability
>      to answer that question, I can live with either alternative.
>
>      Yours,
>
>      Joel
>
>      On 9/7/2022 6:05 PM, Robert Moskowitz wrote:
>      > It might be that the datagram can be interrogated for the Next Header
>      > and that MIGHT mean an update to 8200.
>      >
>      > AH, you can find the NH.  ESP not, as it is in the encrypted part.
>      >
>      > But it is architecturally wrong to call what ROHC or SCHC as carrying
>      > an upper layer protocol.  They carry what is in our architecture a
>      > Transport Layer protocol, acting in many ways as part of the IP layer
>      > itself...
>      >
>      > Fun.
>      >
>      > On 9/7/22 17:35, Joel Halpern wrote:
>      >> My reading of 8200 is that an extension header MUST start with a one
>      >> byte "Next Header" field.  SCHC does not.  Therefore, it is a carried
>      >> / upper layer protocol, not an extension header.  Much like IPv6 (in
>      >> IPv6).  Or UDP (with carrying an application protocol or carrying
>      >> some routing header like GRE, LISP, ...) or ...
>      >>
>      >> Yours,
>      >>
>      >> Joel
>      >>
>      >> PS: I grant we are not fully consistent in this regard.  ESP does not
>      >> have a next-header field.  (AH does).   But if we are going to
>      >> pretend that some headers are extensions headers and some are not, we
>      >> should try to be consistent with the description in 8200 (and 2460).
>      >>
>      >> On 9/7/2022 4:57 PM, Robert Moskowitz wrote:
>      >>>
>      >>>
>      >>> On 9/7/22 16:35, Carsten Bormann wrote:
>      >>>> On 7. Sep 2022, at 22:04, Bob Hinden <[e-mail]> wrote:
>      >>>>> To clarify my question, it only relates to if SCHC should be added
>      >>>>> to the IPv6 Extension Header Types registry.   I continue to think
>      >>>>> that adding it to the IP Protocol Number registry is fine.
>      >>>> I believe the answer should be the same as for 142 (RFC 5858),
>      >>>> which is not in the list.
>      >>>>
>      >>>> I couldn’t find out quickly what an IPv6 Extension Header Type
>      >>>> is(*), so maybe that is an oversight for 142.
>      >>>
>      >>> From my limited understanding and which Protocols are listed as
>      >>> Extension Header Types and which not (other than 142), it is a
>      >>> Protocol that transports other Protocols.
>      >>>
>      >>> Though with that definition, I wonder how HIP got in the list.
>      >>>
>      >>> It is fun to open a can of worms!
>      >>>
>      >>>>
>      >>>> Grüße, Carsten
>      >>>>
>      >>>> (*) An IP protocol number, apparently.
>      >>>> But what specifically does it make an IPv6 Extension Header Type as
>      >>>> well?
>      >>>> The references given in the registry don’t seem to say.
>      >>>>
>      >>>
>      >>> _______________________________________________
>      >>> Int-area mailing list
>      >>> [e-mail]
>      >>> https://www.ietf.org/mailman/listinfo/int-area
>      >
>
>      _______________________________________________
>      Int-area mailing list
>      [e-mail]
>      https://www.ietf.org/mailman/listinfo/int-area
>