Re: [lp-wan] [e-mail]

[Laurent Toutain <[e-mail]>]

Thanks Tom,

I've added these ref to the YANG data model as well as in the draft.

The model is progressing following your advices, a new  version is on the
github https://github.com/lp-wan/datamodel
I will publish a -14 when I will have added the security section.

Laurent

On Thu, Jun 2, 2022 at 11:37 AM t petch <[e-mail]> wrote:

> 768, 7252, 7641, 7959 7967, 8200,
>
> Tom Petch
>
> On 30/05/2022 17:30, t petch wrote:
> > On 30/05/2022 16:31, Laurent Toutain wrote:
> >> Hi Tom,
> >
> > inline
> >
> >>
> >> Thank you for your feed back. It helps us a lot. May I ask you for some
> >> clarifications since it is our first YANG module:
> >>
> >> On Mon, May 30, 2022 at 11:04 AM t petch <[e-mail]> wrote:
> >>
> >>> I see quite a lot wrong with this I-D from an administrative point of
> >>> view and would suggest not putting it forward just yet.
> >>>
> >>> IANA Considerations are what makes a YANG module a YANG module. No IANA
> >>> Considerations, no YANG module.  See RFC8407, YANG Guidelines.
> >>
> >> understood
> >>
> >>> Security Considerations must follow the guidelines in RFC8407 YANG
> >>> Guidelines; this will add a number of references.
> >>
> >> ok
> >
> > Note that it is common practice, but a matter of judgement, as to which
> > nodes are considered sensitive and so worth specific mention.
> >
> > In general, the best authors of YANG in the IETF are in the Netmod WG
> > and so a perusal of recent RFC from that WG may also give you ideas. (as
> > to the worst authors, um, no, not an e-mail list:-(
> >
> >>> References in the YANG module must appear in I-D References.
> >>>
> >>
> >> Ok, This means that IPv6, UDP, CoAP have to be listed.
> >
> > It means that all RFC (or IEEE or ITU-T ...) must be in the I-D
> > References Normative (usually) else Informative as appropriate.  I have
> > not got my notes to hand but there were five I think, may be six, that
> > are in the YANG module but not in the I-D References (certainly 8200 and
> > 768); and any that are added as a result of AD or Last Call or IESG
> > Review must go there as well.
> >
> >>> More subjectively, I have never seen a YANG module with no YANG
> >>> Reference clauses.  Yes, there are references in the descriptive text
> >>> but, for me, this is inadequate.  YANG Reference clauses faclitate
> >>> automated processing, slipping them into the text does not.  I think
> >>> that every Reference should have a YANG Reference clause to at least
> the
> >>> RFC level.
> >>>
> >>
> >> ok, for every identity and grouping for compression and fragmentation we
> >> add the RFC as reference.
> >
> > Well, whereever you have RFCxxxx in the YANG Description clause, I would
> > move it to a YANG Reference clause
> >
> >
> >>> I have never seen a I-D which replicates the YANG in all its detail in
> >>> the body of the I-D (as opposed to using snippets of tree diagams).  A
> >>> recent IESG Review said 'Reference, do not replicate' and I think is
> >>> fundamental to avoiding future problems.  Having the YANG in all its
> >>> detail in more than one place can only lead to inconsistencies and
> >>> contradictions as and when it is updated e.g. as a result of Art and
> >>> IESG reviews.  Also, it makes the I-D harder to read with all the
> >>> unnecessary YANG syntax and semantics therein.
> >
> >> ok, we will update the text.
> >>
> >>>
> >>> I believe that 'All1' will lead to mistakes; mixing alpha and digit in
> >>> an identifier is often a source of error with O, 0, I, l, 1 being
> >>> particularly prone to that.
> >>>
> >>
> >> All1 is something widely used in SCHC to describe the last fragment.
> From
> >> a SCHC perspective All-one looks stranger.
> >
> > Yes.  I did have comments on this in 2021 but do not think I ever
> > communicated them so I checked the state of the I-D in the Datatracker,
> > saw that I had missed WG Last Call, posted my comments and checked the
> > WG list to see that they had arrived only to see that while I was
> > drawing up my comments, your AD had done likewise!  I note that he also
> > commented on All1 but did think that this was likely a term of art and
> > so needed to be as such in the YANG but perhaps worth a comment in
> > Section 2 or some such.
> >
> >>> I would like more in the Abstract; the Introduction reveals that this
> is
> >>> more than a YANG module for the operation of some protocol and the
> >>> Abstract should say that IMHO.
> >>>
> >>
> >> ok, we will update the Abstract.
> >>
> >> Thank you again for all these comments.
> >
> > For me, this was a first pass, on what was to me straight-forward,
> > intending a more technical review later but don't wait for me, I may not
> > get the time.
> >
> >
> >>
> >> Laurent and Ana.
> >>
> >>>
> >>> HTH
> >>>
> >>> Tom Petch
> >>>
>