[MBONED]Re: [iesg] Mike Bishop's No Objection on for: (with COMMENT)

[[e-mail]]

Hi Mahesh,

The mismatch is not detected in the module itself but when consuming reporting state data adhering the module. Allowing to detect anomalies is the whole point of not having a MUST at the first place.

How this can be detected in practice is discussed in the Operational Considerations.

Cheers,
Med

De : Mahesh Jethanandani <[e-mail]>
Envoyé : jeudi 16 avril 2026 02:21
À : Mike Bishop <[e-mail]>
Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [iesg] Mike Bishop's No Objection on for: (with COMMENT)



Ok. I am ambivalent whether it makes more sense to take grouping and then refine it down to just an ip-address or use ip-address directly. I can be persuaded either way.

But my other comment on different constraint still holds, i.e.,

              "Each entry contains parameters for an AMT Relay
               Address identified by the 'family' key. Under
               normal operation, these addresses SHOULD belong
               to the same address family indicated by 'family'.
               Any mismatch is an indication of abnormal
               configuration and is therefore allowed to be
               reported.

How is this mismatch being detected in the module?

Cheers.



On Apr 15, 2026, at 4:05 PM, Mike Bishop <[e-mail]<mailto:[e-mail]>> wrote:

Yes, that was the one. I was surprised a constraint couldn't be placed to use the existing grouping, but restrict it to IP addresses rather than hostnames. If not, that's fine.


________________________________
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 15, 2026 12:56:48 PM
To: Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>
Cc: Mike Bishop <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [iesg] Mike Bishop's No Objection on for: (with COMMENT)

Hi Mahesh,

My reading of Mike’s comment is that he was referring to “Section 4.2.2, paragraph 13”, which seems to me to be this part:

CURRENT:
      Design note: The four data nodes ('gateway-address', 'gateway-
      port', 'local-address', and 'local-port) do not reuse the standard
      "udp-client" grouping defined in
      [I-D.ietf-netconf-udp-client-server] because AMT requires the
      Gateway to be a specific IP address (inet:ip-address), while the
      "udp-client" grouping allows the use of domain names (inet:host).
      Reuse could lead to configuration errors or runtime risks, so a
      custom structure must be defined to enforce this constraint.

Hence, grouping, refine, etc.

Mike, can you please explicit the part you were referring to?

Cheers,
Med

De : Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 15 avril 2026 18:26
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : Mike Bishop <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: [iesg] Mike Bishop's No Objection on for: (with COMMENT)



Hi Med,

On Apr 14, 2026, at 11:49 PM, [e-mail]<mailto:[e-mail]> wrote:

Hi Mike,

Please see one comment inline.

Cheers,
Med

-----Message d'origine-----
De : Mike Bishop via Datatracker <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 15 avril 2026 00:18
À : The IESG <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : [iesg] Mike Bishop's No Objection on draft-ietf-mboned-
amt-yang-08: (with COMMENT)

Mike Bishop has entered the following ballot position for
draft-ietf-mboned-amt-yang-08: No Objection

When responding, please keep the subject line intact and reply to
all email addresses included in the To and CC lines. (Feel free to
cut this introductory paragraph, however.)

------------------------------------------------------------------
COMMENT
------------------------------------------------------------------

Section 4.2.2, paragraph 13

Forgive my lack of YANG expertise, but doesn't YANG support
constraints
to further restrain what values are acceptable? Would a "must" not
have worked
here rather than creating a more constrained type?

[Med] YANG supports some means to constrain data types (when, must, range, etc.). However, there are only a subset of possibilities when it comes to refining a reused grouping (see https://datatracker.ietf.org/doc/html/rfc7950#section-7.13.2 or https://datatracker.ietf.org/doc/html/rfc9907#name-yang-data-node-constraints) This is actually why some constraints are embedded in a description statement.

Are we talking about the same module? I am not sure why grouping is being brought up here. There is no grouping in the module, or a refine statement.

Mike, were you referring to this description or something else?

              "Each entry contains parameters for an AMT Relay
               Address identified by the 'family' key. Under
               normal operation, these addresses SHOULD belong
               to the same address family indicated by 'family'.
               Any mismatch is an indication of abnormal
               configuration and is therefore allowed to be
               reported.

Even if not, how is this mismatch being detected in the module?

Cheers.

Mahesh Jethanandani
[e-mail]<mailto:[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.



Mahesh Jethanandani
[e-mail]<mailto:[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.