Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[mohamed . boucadair]

Hi all,

FWIW, the proposed changes to address the point mentioned by Mahesh [1] can be 
seen at: description text by boucadair · Pull Request #51 · 
boucadair/rfc8407bis 
(github.com)<https://github.com/boucadair/rfc8407bis/pull/51/files>

For convenience, the changes can be tracked here: Diff: 
draft-ietf-netmod-rfc8407bis.txt - 
draft-ietf-netmod-rfc8407bis.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt_2=https://boucadair.github.io/rfc8407bis/boucadair-patch-2/draft-ietf-netmod-rfc8407bis.txt>

Only the template is updated because we do already have the following:

==
Concretely, the IANA Considerations Section SHALL at least
   provide the following information:

   *  ...

   *  An instruction about how to generate the "revision" statement.
==

Cheers,
Med

[1] refer to [yang-doctors] [IANA #1289473] Revision statements in 
IANA-maintained YANG modules 
(ietf.org)<https://mailarchive.ietf.org/arch/msg/yang-doctors/pUCHXggKF2dIeJer8sY-QCz4WTw/>
 for more context.

De : Mahesh Jethanandani 
Envoyé : mercredi 13 mars 2024 03:51
À : BOUCADAIR Mohamed INNOV/NET 
Cc : netmod@ietf.org
Objet : Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

Hi Med,

Thanks for driving this effort on updating RFC 8407.

One additional change coming your way, is to address the question of how IANA 
is supposed to handle updates to IANA YANG modules. The YANG doctors are 
currently debating those changes. Once agreed, we will bring that discussion 
here, and will need to update rfc8407bis to provide guidance to authors who 
update an IANA module. Stay tuned.

Cheers.


On Mar 12, 2024, at 5:00 AM, 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:

Hi all,


  *   A candidate -10 is ready to address 3 comments from Jan:

 *   Long trees
 *   Updated security template
 *   Minor tweaks to Section 3.8
 *   The changes circulated on the list can be seen here: Compare Editor's 
Copy to 
Datatracker<https://boucadair.github.io/rfc8407bis/#go.draft-ietf-netmod-rfc8407bis.diff>

  *   Jan raised two other comments (short/uniqueness of prefixes + how to 
handle "not set") but no changes were made per the feedback received on the 
list.
  *   Next steps:

 *   Submit -10 right after IETF#119
 *   WGLC

Cheers,
Med



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.
___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>






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.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Andy Bierman]

Hi,

I cannot find this email wrt/ short prefixes


   - (short/uniqueness of prefixes


Other SDOs are using a prefix in their prefixes (e.g. openconfig).
It is common for servers to have both "if:interfaces" and
"oc-if:interfaces" subtrees.

It might be a good idea to have a guideline that all IETF YANG modules
SHOULD
use the "ietf-" string in the module prefix.  This should reduce the chance
of name collisions
between SDOs and vendors, and helps identify the module as an IETF module.


Andy



On Tue, Mar 12, 2024 at 10:51 AM Mahesh Jethanandani <
mjethanand...@gmail.com> wrote:

> Hi Med,
>
> Thanks for driving this effort on updating RFC 8407.
>
> One additional change coming your way, is to address the question of how
> IANA is supposed to handle updates to IANA YANG modules. The YANG doctors
> are currently debating those changes. Once agreed, we will bring that
> discussion here, and will need to update rfc8407bis to provide guidance to
> authors who update an IANA module. Stay tuned.
>
> Cheers.
>
> On Mar 12, 2024, at 5:00 AM, mohamed.boucad...@orange.com wrote:
>
> Hi all,
>
>
>- A candidate -10 is ready to address 3 comments from Jan:
>   - Long trees
>   - Updated security template
>   - Minor tweaks to Section 3.8
>   - The changes circulated on the list can be seen here: Compare
>   Editor's Copy to Datatracker
>   
> 
>- Jan raised two other comments (short/uniqueness of prefixes + how to
>handle “not set”) but no changes were made per the feedback received on the
>list.
>- Next steps:
>   - Submit -10 right after IETF#119
>   - WGLC
>
>
> Cheers,
> Med
>
> 
> 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.
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
>
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Mahesh Jethanandani]

Hi Med,

Thanks for driving this effort on updating RFC 8407. 

One additional change coming your way, is to address the question of how IANA 
is supposed to handle updates to IANA YANG modules. The YANG doctors are 
currently debating those changes. Once agreed, we will bring that discussion 
here, and will need to update rfc8407bis to provide guidance to authors who 
update an IANA module. Stay tuned.

Cheers.

> On Mar 12, 2024, at 5:00 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi all, 
>  
> A candidate -10 is ready to address 3 comments from Jan:
> Long trees
> Updated security template
> Minor tweaks to Section 3.8
> The changes circulated on the list can be seen here: Compare Editor's Copy to 
> Datatracker 
> 
> Jan raised two other comments (short/uniqueness of prefixes + how to handle 
> “not set”) but no changes were made per the feedback received on the list.  
> Next steps:
> Submit -10 right after IETF#119
> WGLC
>  
> Cheers,
> Med
> 
> 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.
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 

Mahesh Jethanandani
mjethanand...@gmail.com






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod