Re: [Roll] Alvaro's review on turnon Rfc 8138 07

Hi Pascal,

Following my understanding, the action points are?:

- Deleting reference to capabilities from Introduction and (section 4?,
section 5.2? and section 5.3?)
- Clarifying behaviour in SM and Non-SM:

SM:

Parent to child where child is RUL ( including RAL  that does not
understand compression MUST acts as a RUL )=> decompress

Everywhere else => forward compressed (since it is assumed that
intermediate routers supports compression)

Non-SM:

The default is to uncompress once the SRH is fully consumed.

I understand that the ideal case would be turn on compression when all
nodes support it, but in real use cases could be nodes not supporting it
and must be part of the network anyway and the above it is to reflect how
to act on those cases.

Thank you in advance,

Ines.

On Wed, Jul 8, 2020 at 3:07 PM Pascal Thubert (pthubert) <pthubert=
40cisco.com@dmarc.ietf.org> wrote:

> OK, so how do we proceed?
>
> 1) I could remove it all;
> Or
> 2) I could keep the second scenario in appendix and explain that in NS
> mode we can use the compressed format to the penultimate hop.
>
> What do you guys think?
>
> Pascal
>
> > -----Original Message-----
> > From: Roll <roll-bounces@ietf.org> On Behalf Of Michael Richardson
> > Sent: mardi 7 juillet 2020 13:33
> > To: Routing Over Low power and Lossy networks <roll@ietf.org>
> > Cc: roll-ads@ietf.org
> > Subject: Re: [Roll] Alvaro's review on turnon Rfc 8138 07
> >
> >
> > Rahul Jadhav <nyrahul@outlook.com> wrote:
> >     >  The problem with these additional fields is that they will be
> >     >  redundant once we have capabilities.
> >
> >     > I feel we do not need to handle the case of "forgotten nodes".
> >
> > This.
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -
> > = IPv6 IoT consulting =-
> >
> >
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>