[Teas] Re: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt

[Italo Busi <[e-mail]>]

Thanks Med

I have updated the draft in github to address most of your comments. You can check the diff at:

https://author-tools.ietf.org/diff?doc_1=draft-ietf-teas-rfc8776-update-14&url_2=https://raw.githubusercontent.com/tsaad-dev/te/refs/heads/master/drafts/te-types-update/draft-ietf-teas-rfc8776-update.txt

These are the comments for which I would need more input from the TEAS WG:

> * " The derived identities SHOULD describe the ..": I wouldn't surprised if you
> receive a comment about why this is not a MUST. You may explain an
> exception in the text if you have one in mind.

An exception is the number of hops which do not have a measurement unit, so it cannot be a MUST. Spelling out the exception is not future proof: we do not wish to precluding future definitions of other identities similar which do not have measurement units.

> * I like this text, but is this used by other standard models outside IETF?
> 
> CURRENT:
>          The container has been renamed as 'explicit-route-objects'.
>          This change is not affecting any IETF standard YANG models
>          since this grouping has not yet been used by any YANG model
>          defined in existing IETF RFCs.
> 

The text reflects the decision based on the discussion on the list:

https://mailarchive.ietf.org/arch/msg/teas/cmf7KsRBxFQZ6oaf-mzWTdZxAYQ/

IMHO, it is quite unlikely that other SDOs are importing this grouping from RFC 8776 but I do not think we can write anything about this in an IETF draft/RFC so better to keep silent on this point

> * I still find identifiers such as " path-computation-error-destination-unknown-
> in-domain" to be toooooo long, but...

At this stage, there is nothing I can do.

Just a side comment:

> * "revision  2024-10-30" and file name should be consistent. Fix the date.

This is another example of why I do not like duplicated information to be manually kept updated: this duplicated information quickly gets out of synch if authors or reviewers are not carefully enough to double check it

An automatic tool to automatically keep this text in synch or, at least, flag the nit before submission would be very useful

Italo

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: venerdì 8 novembre 2024 08:18
> To: Italo Busi <[e-mail]>; [e-mail]
> Subject: RE: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt
> 
> Hi Italo,
> 
> Many thanks for the effort put in this document.
> 
> I used a diff vs the original RFC to do a final check: https://author-
> tools.ietf.org/diff?doc_1=rfc8776&doc_2=draft-ietf-teas-rfc8776-update-
> 14&wdiff=1
> 
> For the record, I consider the comments I raised as closed.
> 
> FWIW, find below some nits/comments that you can consider for a future
> iteration when you will have other reviews:
> 
> * I would invert the ordering of 1.2/1.3 so that mapping with 8776 is preserved
> * Introduction: s/ YANG models and obsoletes/ YANG modules and obsoletes
> (or YANG data models and obsoletes)
> * Section 3.1: To ease referring by future documents, you may convert the text
> starting with " The "xxx" module contains the following " into subsections
> * Idem as previous comment for Section 3.2
> * Section 3.1: s/No standard LPS provisioning/No standard LP provisioning
> * " The derived identities SHOULD describe the ..": I wouldn't surprised if you
> receive a comment about why this is not a MUST. You may explain an
> exception in the text if you have one in mind.
> * Don't be restrictive in how this will be used:
> 
> OLD:
>    path-computation-error-reason:  A base YANG identity for reporting
>       path computation error reasons as defined in Section 3.1.1.
> 
> NEW:
>    path-computation-error-reason:  A base YANG identity for indicating
>       path computation error reasons as defined in Section 3.1.1.
> 
> (idem in the wording in 3.1.1)
> 
> * These entries are listed as identities, while these are groupings. Please fix
> that:
> 
> CURRENT:
> 
>    The "ietf-te-types" module contains the following YANG reusable
>    identities:
>    ...
>    explicit-route-hop:  A YANG grouping that defines supported explicit
>       routes as defined in [RFC3209] and [RFC3477].
>    ...
> 
>    encoding-and-switching-type:  This is a common grouping to define the
>       LSP encoding and switching types.
> 
> * Explicit this is to clarify what an IANA module is not used here
> 
> OLD:
>    The derived identities are defined in the "ietf-te-types" module
>    because there are error reasons which are:
> 
> NEW:
>    The derived identities are defined in the "ietf-te-types" module
>    instead of an IANA-maintained module because there are error reasons
> which are:
> 
> * Section 3.2: I would split the identities vs groupings
> * I like this text, but is this used by other standard models outside IETF?
> 
> CURRENT:
>          The container has been renamed as 'explicit-route-objects'.
>          This change is not affecting any IETF standard YANG models
>          since this grouping has not yet been used by any YANG model
>          defined in existing IETF RFCs.
> 
> * "revision  2024-10-30" and file name should be consistent. Fix the date.
> * I still find identifiers such as " path-computation-error-destination-unknown-
> in-domain" to be toooooo long, but...
> * " "At least one node identifier MUST be present.";  I don't think you need the
> normative language here as you already have a must statement.
> * Idem in
> 
> "                 "At least one node identifier and at least one Link
>                  Termination Point (LTP) identifier MUST be present."; "
> 
> 
> Cheers,
> Med
> 
> 
> Orange Restricted
> 
> > -----Message d'origine-----
> > De : Italo Busi <Italo.Busi=[e-mail]>
> > Envoyé : mardi 5 novembre 2024 00:10
> > À : [e-mail]
> > Objet : [Teas] FW: New Version Notification for draft-ietf-teas-
> > rfc8776-update-14.txt
> >
> > Dear TEAS WG and chairs,
> >
> > I have just uploaded an updated version of the draft addressing all
> > the comments received during the second Working group last call of
> > draft-ietf-teas-rfc8776-update-13 and discussion on the WG mailing
> > list
> >
> > I believe the draft is not ready to go to IESG
> >
> > Thanks, Italo (on behalf of co-authors/contributors)
> >
> > > -----Original Message-----
> > > From: [e-mail] <[e-mail]>
> > > Sent: martedì 5 novembre 2024 01:05
> > > To: Aihua Guo <[e-mail]>; Igor Bryskin
> > > <[e-mail]>; Italo Busi <[e-mail]>;
> > Tarek Saad
> > > <[e-mail]>; Xufeng Liu <[e-mail]>
> > > Subject: New Version Notification for
> > > draft-ietf-teas-rfc8776-update-14.txt
> > >
> > > A new version of Internet-Draft draft-ietf-teas-rfc8776-update-
> > 14.txt
> > > has been successfully submitted by Italo Busi and posted to the
> > IETF repository.
> > >
> > > Name:     draft-ietf-teas-rfc8776-update
> > > Revision: 14
> > > Title:    Common YANG Data Types for Traffic Engineering
> > > Date:     2024-11-05
> > > Group:    teas
> > > Pages:    154
> > > URL:
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-teas-rfc8776-update-
> >
> 14.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c442cf5
> 2
> >
> 2b4778426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> C0
> > %7C638663622429788248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDA
> >
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
> >
> a=hApMC%2Bb%2FKohyTzQJBIZ9ac0tKOzIqFZoVFo14Erf0IM%3D&reserved=0
> > > Status:
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teas-rfc8776-
> >
> update%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c4
> 42c
> >
> f522b4778426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> >
> 7C0%7C638663622429807585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAw
> >
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&
> s
> >
> data=2%2FJV94ILkIg0Gr6M29gWhYPnsVMFv5%2F7YM9dsZs%2Bs7c%3D&rese
> rve
> > d=0
> > > HTMLized:
> > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fdata
> > > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teas-rfc8776-
> > &data=05%7C02%
> > >
> >
> 7Cmohamed.boucadair%40orange.com%7C26c442cf522b4778426208dcfd2e
> 47
> > 16%7C
> > >
> >
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638663622429822216%
> 7CU
> > nknow
> > >
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > WwiLC
> > >
> >
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xYJwo5A14GdYtVLDsrzVXxHSigD1js
> g1w
> > Jx9tL
> > > FoMEo%3D&reserved=0
> > > update
> > > Diff:
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-teas-rfc8776-
> >
> &data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c442cf522b4
> 778
> >
> 426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638
> >
> 663622429836473%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQI
> >
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hFW
> a
> > ZMR8jikNKAVcwSRrPYk%2FXPnzkc%2FQSlW2225ZksM%3D&reserved=0
> > > update-14
> > >
> > > Abstract:
> > >
> > >    This document defines a collection of common data types,
> > identities,
> > >    and groupings in YANG data modeling language.  These derived
> > common
> > >    data types, identities and groupings are intended to be
> > imported by
> > >    other modules, e.g., those which model the Traffic
> > Engineering (TE)
> > >    configuration and state capabilities.
> > >
> > >    This document obsoletes RFC 8776.
> > >
> > >
> > >
> > > The IETF Secretariat
> > >
> >
> > _______________________________________________
> > Teas mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> _________________________________________________________________
> ___________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.