Re: [CCAMP] Intdir telechat review of draft-ietf-ccamp-layer1-types-16

[Dirk Hugo <[e-mail]>]

Okay, thanks for that! I am fine with your adaptions.
Best regards Dirk

On Wed, Feb 14, 2024, 2:31 PM Italo Busi <[e-mail]> wrote:

> Dear Dirk,
>
> Thank you for the review, the authors have updated the document to address
> your comments and posted the updated document as
> draft-ietf-ccamp-layer1-types-17.
>
> For clarity we have included the proposed resolution for each issue
> identified in the text below [Haomian & Italo].
>
> Again, thanks for the support and review.
>
> Authors, Haomian and Italo.
>
> > -----Original Message-----
> > From: Dirk Von Hugo via Datatracker <[e-mail]>
> > Sent: sabato 9 dicembre 2023 23:45
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]; last-
> > [e-mail]
> > Subject: [CCAMP] Intdir telechat review of
> draft-ietf-ccamp-layer1-types-16
> >
> > Reviewer: Dirk Von Hugo
> > Review result: Ready with Nits
> >
> > I have reviewed this document as part of the INT area directorate's
> ongoing
> > effort to review all IETF documents being processed by the IESG.  These
> > comments were written primarily for the benefit of the Internet area
> > directors.
> > Document editors and WG chairs should treat these comments just like any
> > other last call comments.
> >
> > The summary of the review is 'Ready with nits'.
> >
> > General comment on the title 'A YANG Data Model for Layer 1 Types' is
> that
> > the draft addresses specifically Layer 1 optical networks - a fact which
> may
> > be referred to also in the title. As I am neither an expert in YANG nor
> in
> > optical networks I cannot comment on those technical issues but hope that
> > has been already discussed elsewhere. In addition to other reviews as the
> > Gen-ART review by Dale
> > (
> https://datatracker.ietf.org/doc/review-ietf-ccamp-layer1-types-16-genart-
> > lc-worley-2023-11-16/)
> > I found further minor nits to be corrected/clarified before publication:
> >
> > p.1:
> > topology, tunnel, client signal adaptation and service => topology,
> tunnel,
> > client signal adaptation, and service
> >
>
> [Haomian & Italo] Agree. Text updated.
>
> > p.2:
> > data types, groupings and identities => data types, groupings, and
> identities
>
> [Haomian & Italo] Agree. Text updated.
>
> > Optical Transport Networking, => Optical Transport Networking (OTN),
>
> [Haomian & Italo] Agree. Text updated.
>
> >
> > p.3:
> > groupings, typedef and identities, => groupings, typedef, and identities,
>
> [Haomian & Italo] Agree. Text updated.
>
> > Layer 1 TE types (i.e. typedef, => Layer 1 TE types (i.e., typedef,
> specified in
>
> [Haomian & Italo] Agree. Text updated.
>
> > ietf-te-types in [I-D.ietf-teas-rfc8776-update] => specified as
> ietf-te-types in
> > [I-D.ietf-teas-rfc8776-update]
>
> [Haomian & Italo] Agree. Text updated.
>
> >
> > p.4:
> > specified in ietf-layer1-types in this document. => specified as
> ietf-layer1-
> > types in this document.
>
> [Haomian & Italo] Agree. Text updated.
>
> >
> > p.7:
> > a label-end, a label-step and a range-bitmap. => a label-end, a
> label-step, and
> > a range-bitmap.
>
> [Haomian & Italo] Agree. Text updated.
>
> > TPN assignment rules depends => PN assignment rules
> > depend OR PN assignment rule depends
>
> [Haomian & Italo] Agree. Text updated as "TPN assignment rules depend"
>
> > [ITU-T_G.709], defines six types of
> > ODUflex:
> > ODUflex(CBR), ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP),
> > ODUflex(IMP,s) and => [ITU-T_G.709] defines six types of ODUflex:
> > ODUflex(CBR), ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP),
> > ODUflex(IMP,s), and
>
> [Haomian & Italo] Agree. Text updated.
>
> >
> > p.9:
> > to defines the value of s=5 x n => to define the value of s=5 x n is
> defined in
>
> [Haomian & Italo] Agree. Text updated.
>
> > section 12.2.6 => is defined in Section 12.2.6
>
> [Haomian & Italo] Agree. Text updated.
>
> > Section 5.1 and 5.2 of [RFC7139]
> > defines => Sections 5.1 and 5.2 of [RFC7139]
>
> [Haomian & Italo] Agree. Text updated.
>
> > define an ODUflex LSPs => an
> > ODUflex LSP OR ODUflex LSPs [if I didn't misunderstand the sentence]
>
> [Haomian & Italo] Agree, but we adjusted the text updated.
>
> > the
> > OTN LTPs [meaning of LTP neither defined here nor in RFC 7062]
>
> [Haomian & Italo] Agree, but we adjusted the text updated.
>
> > the rules
> > defined any other ODUflex type => the rules defined for any other ODUflex
> > type
>
> [Haomian & Italo] Agree, but we adjusted the text updated.
>
> >
> > p.10:
> > LSP does or does support => LSP does or does not support
> >
>
> [Haomian & Italo] Agree, but we adjusted the text updated.
>
> > p.45:
> > is reportd for => is reported for
> >
>
> [Haomian & Italo] Agree, but we adjusted the text updated.
>
> > Thanks for the work and best regards
> > Dirk
> >
> >
>
>