Re: [CCAMP] WG adoption poll on draft-zheng-ccamp-client-topo-yang-10

[tom petch <[e-mail]>]

From: Italo Busi <[e-mail]>
Sent: 09 October 2023 20:19

Hi Tom,

We have just submitted draft-ietf-ccamp-eth-client-te-topo-yang-05 addressing all your comments as discussed below

<tp>
Indeed, much improved but you know me, cannot stop commenting

You need I-D references for
MEF 10.3
IEEE 802.1Q

Prefix table etht lacks [] 

Note below prefix table is wrong -  YYYY is not this draft!

Security Considerations do not follow the YANG Guidelines

English is not quite IETF English
e.g. in this draft, we augment
perhaps
this document augments
but you may prefer to leave such until later.

Tom Petch



Thanks, Italo

> -----Original Message-----
> From: Italo Busi <[e-mail]>
> Sent: giovedì 18 febbraio 2021 22:25
> To: 'tom petch' <[e-mail]>; Daniele Ceccarelli
> <daniele.ceccarelli=[e-mail]>; CCAMP
> <[e-mail]>
>
> Hi Tom,
>
> Thanks for your useful comments:
>
> > The YANG module is totally devoid of references, which has to be
> > fixed, at least in part, at some stage and the earlier it is fixed,
> > the less time consuming reviewing is.
> >
>
> We will add references when applicable
>
> > s.5 says there is no open issue in this version.  The text gives the
> > lie to this with 'open issue' in four places
> >
>
> To avoid inconsistent information, we will remove section 5 and use only
> github to track open issues
>
> > there are YANG statements commented out.  The last time I saw this it
> > was because the Author could not make the YANG work
> >
>
> We will review the YANG code and track these as open issues in github
>
> > It is another of those module that is really 100 or so independent
> > YANG fragments in a different order to those other modules that are
> > really 100 or so independent YANG fragments.  As was said in a recent
> > IESG review, it is a shame we cannot go back and change the TEAS i.e.
> > they got the underlying structure wrong:-(
> >
>
> Are you referring to the multiple augment statements to augment the TE
> label/bandwidth information defined in RFC8795?
>
> They are based on the guidelines provided by section 6 of RFC8795.
>
> > the choice of YANG prefix makes comprehension harder
>
> There is an on-going discussion within the WG: we will align with the outcome
> of that discussion
>
> Italo (on behalf of co-authors)
>
> > -----Original Message-----
> > From: tom petch [mailto:[e-mail]]
> > Sent: mercoledì 10 febbraio 2021 12:20

> >
> > From: CCAMP <[e-mail]> on behalf of Daniele Ceccarelli
> > <daniele.ceccarelli=[e-mail]>
> > Sent: 09 February 2021 12:28
> >
> > CCAMP,
> >
> > All the IPR declarations regarding
> > draft-zheng-ccamp-client-topo-yang-10have
> > been collected, this starts the polling for its adoption by CCAMP.
> >
> > The poll will last 2 weeks and will end on Tuesday February 23rd.
> >
> > Please send email to the list indicating "yes/support" or "no/do not support"
> > and a motivation for  your reply, mandatory for the "not support" and
> > nice to have for the "support".
> >
> > <tp>
> > This will be an expensive I-D to work on.
> >
> > The YANG module is totally devoid of references, which has to be
> > fixed, at least in part, at some stage and the earlier it is fixed,
> > the less time consuming reviewing is.
> >
> > s.5 says there is no open issue in this version.  The text gives the
> > lie to this with 'open issue' in four places
> >
> > there are YANG statements commented out.  The last time I saw this it
> > was because the Author could not make the YANG work
> >
> > It is another of those module that is really 100 or so independent
> > YANG fragments in a different order to those other modules that are
> > really 100 or so independent YANG fragments.  As was said in a recent
> > IESG review, it is a shame we cannot go back and change the TEAS i.e.
> > they got the underlying structure wrong:-(
> >
> > the choice of YANG prefix makes comprehension harder
> >
> > Tom Petch
> >
> > Thanks,
> >
> > Daniele & Fatai
> >
> >