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

[Mahesh Jethanandani <[e-mail]>]

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]> 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] <[e-mail]>
> Sent: Wednesday, April 15, 2026 12:56:48 PM
> To: Mahesh Jethanandani <[e-mail]>
> Cc: Mike Bishop <[e-mail]>; The IESG <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[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]> 
> Envoyé : mercredi 15 avril 2026 18:26
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : Mike Bishop <[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)
>  
> 
> 
> 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]