[Teas] Removing default statements from RFC8776 (was RE: Working group last call: draft-ietf-teas-rfc8776-update-10)

[Italo Busi <[e-mail]>]

TEAS WG,

IMHO, the WG LC  comment from Med (see below) about removing default statements require some discussion within the WG

The only default value added in draft-ietf-teas-rfc8776-update is the following (see also the diff files in Appendix A.1 and Appendix A.2):

    leaf tiebreaker {
      type identityref {
        base path-tiebreaker-type;
      }
      default "te-types:path-tiebreaker-random";
      description
        "The tiebreaker criteria to apply on an equally favored set
         of paths, in order to pick the best.";
    }
If there are no objections from the WG, I would propose to remove this default statement and keep the default value for the leaf tiebreaker as implementation-specific.

All the other default statements have been already defined in RFC8776 and their removal will be an NBC change according to section 11 of RFC7950 so I am not sure it is worthwhile reviewing all these default statements now or consider this topic for discussion in a future update to RFC8776

What is the WG opinion/suggestion?

Thanks, Italo (on behalf of co-authors/contributors)

From: [e-mail] <[e-mail]>
Sent: lunedì 22 aprile 2024 08:13
To: Oscar González de Dios <[e-mail]>; 'TEAS WG' <[e-mail]>
Cc: 'TEAS WG Chairs' <[e-mail]>
Subject: Re: [Teas] Working group last call: draft-ietf-teas-rfc8776-update-10

Hi all,

Many thanks to the authors for being meticulous and identifying each update vs. 8776.

Please find below some comments, fwiw:

# Major comments

## Offload path-computation-error-reason to an IANA-maintained model. The current design is suboptimal. Please refer to the 84047bis on these matters.

## Default values may be problematic when reusing the groupings. For example, if the same grouping is used in some kind of profile but the grouping is called for in addition to reference to that profile, the default value will override what is inherited from the profile. I would remove the default statement, but add the default value in the description text.

## Mandatory statements may also be problematic and would prevent some usages. For example, a CIR/CBS must always be present, while this is not optimal when profiling/templates are used.
### BTW, please consider aligning the bandwidth structure with the bandwidth groupings in the AC and slicing models: add pir/pbs.

## It seems that the module focuses mainly on configuration, while this should cover also reporting purposes. Please update the description of the some nodes to reflect this + consider new groupings:
### for example, performance-metrics-attributes-packet and one-way-performance-metrics-packet can't be reused for stats. Please consider providing new groupings (with the same nodes) but with gauge type.

## Minor comments

## I would avoid changing the structure of sections to ease mapping with 8776. For example, I would keep 1.1/1.2 as it was in 8776.
## Acronyms: order them in an alphabetic order. Not sure the reasoning of the current ordering.
## Include trees with -print-groupings or a pointer to where to retrieve the full trees.
## The tree in 3.2 is not aligned with the YANG module: the bandwidth tree indicates that CIR/CBS are optional (with ?), while these are tagged as mandatory in the module.
## Consider adding explicit pointers to the specific section(s) of cited documents. It is not always easy to find which part of a document is relevant.
### This should be fixed for both the narrative text and the YANG models.
## I have doubts about many of enums (e.g., path-type). Please check that these are justified vs using identities.
## union of union types (e.g., te-gen-node-id) includes overlapping types (e.g., inet:ip-address vs. inet:ipv6-address-no-zone): consider simplifying.
## I think that many informative references should move to be normative. For example, RFC6370 should be normative. Please double check.
## MEF 6.2 EVC Ethernet Services Definitions Phase 3 - MEF : standard superseded. Please double check this reference.

## I filled a PR with editorial fixes, broken refs, etc.: https://github.com/tsaad-dev/te/pull/277/files

Thank you.

Cheers,
Med



From: Sergio Belotti (Nokia)
Sent: Monday, April 15, 2024 11:06 AM
To: Oscar González de Dios <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Teas] Working group last call: draft-ietf-teas-rfc8776-update-10

Hi Oscar, WG,

I found an issue in section 3.1 where te-node-id description is not aligned with the new typedef supporting also IPV6 format .
Provided that authors can fix this misalignment I've reviewed this document and believe it is ready for publication.

Thanks
Sergio



From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Oscar González de Dios
Sent: Friday, April 12, 2024 10:17 AM
To: 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] Working group last call: draft-ietf-teas-rfc8776-update-10


Algunos contactos que recibieron este mensaje no suelen recibir correos electrónicos de [e-mail]<mailto:[e-mail]>. Por qué esto es importante<https://aka.ms/LearnAboutSenderIdentification>




CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Dear TEAS WG colleagues,

This email starts a two-week working group last call on https://datatracker.ietf.org/doc/draft-ietf-teas-rfc8776-update/

The working group last call ends on April 26th 2024.
Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!
This is useful and important, even from authors.
Please note that no IPR was disclosed for this document.

Thank you,
              Oscar, Pavan, Lou


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

____________________________________________________________________________________________________________

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.