Subject: [lp-wan] Interim minutes

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Dec 2018 05:00:46 +0000

Dear all :

The proceedings of the interim yesterday are posted on the datatracker https://datatracker.ietf.org/meeting/interim-2018-lpwan-17/session/lpwan.
A recording was made of the discussion on the WGLC, the link is in the minutes.
The source for the minutes is still modifiable on http://etherpad.tools.ietf.org:9000/p/lpwan?useMonospaceFont=true Please let us know if any correction is needed.
As discussed at the interim, you'll also find the slides of the webinar las week attached as proceedings to this session.

Many thanks to all attendees;

Pascal

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 12 Dec 2018 22:21:01 -0800

Hello folks,

First, thanks for the minutes for the interim meeting, as well as for 
the many efforts to resolve comments.

I gather from the minutes that there will be another revision of the 
SCHC document in the relatively near future, months before IETF 104.  
This is good news -- and again, many thanks.

I wonder how this interacts with a declaration about whether or not WGLC 
is complete for the document.  The minutes seem to indicate that WGLC is 
complete when revision ---18.txt is published.  To me, that means that 
WG comments are no longer wanted for the new revision.  Or, if the 
members of the working group are expected to comment on the new work, 
doesn't that mean that Last Call is not yet done?

Notably, some of the text for the earlier Last Call (prior to IETF 103) 
suggested that comments about compression / decompression, profiles, 
terminology, and so on were somehow off limits.  And yet, it seems to me 
that a lot of improvements were made in those sections as well.  Besides 
that, I was curious about how it could be that the document would be 
ready for Last Call after such a major rewrite (improvement!!) of the 
fragmentation sections between revisions 16 and 17.

All in all, I find it a bit confusing about what Last Call means, as 
applied to soliciting comments and possible error corrections in the 
document.  To me, completing Last Call means that the Working Group has 
completed work on the document.  After a bit of shepherding, the 
document is then expected to be ready for wider review (IETF last call) 
and maybe for avoiding conflict with work in other areas of the IETF 
(IESG review).  Is that wrong?

Regards,
Charlie P.

On 12/12/2018 9:00 PM, Pascal Thubert (pthubert) wrote:
>
> Dear all :
>
> The proceedings of the interim yesterday are posted on the datatracker 
> https://datatracker.ietf.org/meeting/interim-2018-lpwan-17/session/lpwan.
>
> The source for the minutes is still modifiable on 
> http://etherpad.tools.ietf.org:9000/p/lpwan?useMonospaceFont=true 
> Please let us know if any correction is needed.
>
> As discussed at the interim, you’ll also find the slides of the 
> webinar las week attached as proceedings to this session.
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 12 Dec 2018 22:29:30 -0800

Hello Pascal and all,

Regarding the issue about Appendix D, as mentioned in the minutes...

Not all of the text in Appendix D needs to be normative.

But there are some parameters in the document that are mandated to have 
values in a profile.  Those parts need to be collected together into a 
normative section that is not relegated to an appendix.

I think the Profile section would comfortably fit in between the 
compression/decompression specification and the fragmentation 
specification.  Notably, those two specifications are mostly independent.

Regards,
Charlie P.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Dec 2018 13:29:29 +0000

Hello Charlie :

I can see your logic and we discussed it at the interim. We ended up with a consensus decision that we will define the full profile in another document.
We'll probably need to use Yang, go through the Tang doctors and compiler, all the 9 yards. This is really a new and separate item.

For now, the SCHC document indicates some profile information but does not explicitly aim at listing all the profile information as a normative list.
We are happy with that. We'll decide the complete list once we have enough return from implementation, chicken and an egg.
The profile data model will probably be packaged with the protocol that pushes it to the network gateway side. We have provision in the recharter for that.

All the best,

Pascal

From: Charlie Perkins <[email-masked]>
Sent: jeudi 13 décembre 2018 10:30
To: Pascal Thubert (pthubert) <[email-masked]>; lp-wan <[email-masked]>
Subject: Profiles

Hello Pascal and all,

But there are some parameters in the document that are mandated to have values in a profile.  Those parts need to be collected together into a normative section that is not relegated to an appendix.

I think the Profile section would comfortably fit in between the compression/decompression specification and the fragmentation specification.  Notably, those two specifications are mostly independent.

Regards,
Charlie P.

Pascal

lp-wan mailing list

[email-masked]<mailto:[email-masked]>