Re: [Last-Call] [lp-wan] [yang-doctors] Yangdoctors last call review of draft-ietf-lpwan-schc-yang-data-model-14

["Joe Clarke \(jclarke\)" <jclarke=40cisco.com@xxxxxxxxxxxxxx>]

Yes, it can.  The largest issues have been addressed.  There are now more nits left.

 

Joe

 

From: Eric Vyncke (evyncke) <evyncke=40cisco.com@xxxxxxxxxxxxxx>
Date: Friday, August 5, 2022 at 05:52
To: Joe Clarke (jclarke) <jclarke@xxxxxxxxx>, Laurent Toutain <laurent.toutain@xxxxxxxxxxxxxxxxx>
Cc: yang-doctors@xxxxxxxx <yang-doctors@xxxxxxxx>, draft-ietf-lpwan-schc-yang-data-model.all@xxxxxxxx <draft-ietf-lpwan-schc-yang-data-model.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, lp-wan@xxxxxxxx <lp-wan@xxxxxxxx>
Subject: Re: [lp-wan] [yang-doctors] Yangdoctors last call review of draft-ietf-lpwan-schc-yang-data-model-14

Hello Joe

 

Thank you again for your YANG doctors’ review. With the -15 and Laurent’s answer, do you consider that your ‘not ready’ review comments have been addressed ?

 

I.e., can this document move forward ?

 

Regards

 

-éric

 

 

From: lp-wan <lp-wan-bounces@xxxxxxxx> on behalf of "Joe Clarke (jclarke)" <jclarke=40cisco.com@xxxxxxxxxxxxxx>
Date: Tuesday, 2 August 2022 at 19:51
To: Laurent Toutain <laurent.toutain@xxxxxxxxxxxxxxxxx>
Cc: "yang-doctors@xxxxxxxx" <yang-doctors@xxxxxxxx>, "draft-ietf-lpwan-schc-yang-data-model.all@xxxxxxxx" <draft-ietf-lpwan-schc-yang-data-model.all@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>, "lp-wan@xxxxxxxx" <lp-wan@xxxxxxxx>
Subject: Re: [lp-wan] [yang-doctors] Yangdoctors last call review of draft-ietf-lpwan-schc-yang-data-model-14

 

 

tried to clarify 

 

 description

        "Direction Indicator, indicate if this field must be

        consider for rule selection or ignored based on the

        direction (bi directionnal, only uplink, or only

        downlink).";

 

 

[JMC] This is a bit clearer.

 

[JMC] When I read Section 4.7 of RFC 8407 I tend to think that you should target to augment the choice rather than add empty case statements that _might_ be used in the future.  The name of the case is less important than the nodes that will come under it anyway.

 

[JMC]. I still see the empty case statements.  Is that because you have this existing augmentation already?

 

tainers for compression and fragmentation?

 

I don't think if-feature is enough. feaures were introduce since in some cases, we need only compression (such as in RFC 8824 where we specify SCHC at the application layer), or only fragmentation (there is a proposal to use only frag in NB_IoT), but in most scenarii we may have both, but a rule 

can only be of one type.

 

To solve that, we introduced a new mandatory field (rule-nature) which will accept identify references we have defined. In the grouping there is now a must that tests the rule's nature. For compression it is at the beginning of the list. For fragmentation we have an enumeration of leaf; so we put the MUST in a mandatory leaf.

 

The draft is also updated to cover that change. I tested it on yangson and it reacted has expected. 

 

I think it looks better.  Though this special rule-nature node’s description could use some more details 😊

 

Also, I had a typo above.  When I said RFC8349, I meant RFC8340 for the YANG trees.  There you would need an informative reference.

 

Joe

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call