Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Eliot Lear [mailto:[email protected]]
> Envoyé : vendredi 28 mai 2021 13:43
> À : BOUCADAIR Mohamed TGI/OLN <[email protected]>;
> [email protected]
> Objet : Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing
> 
> Hi Med,
> 
> Thanks for your comments.  Please see below.
> 
> On 28.05.21 11:18, [email protected] wrote:
> > Hi Eliot, all,
> >
> > This extension makes sense to me. I support it to be adopted in
> opsawg (where 8520 was developed).
> >
> > That's said, this draft does not update 8520. I suggest to remove
> "Updates: 8520 (if approved)"

[Med] I guess this is covered by on one of your replies below, but still don't 
see which part in 8520 is updated here. If you have an excerpt to share, that 
would be helpful. 

...
> 
> > (3)
> >
> > You may remove the note about normative language in the description
> of the module given that you don't use it.
> 
> I think we need to discuss this more, because we SHOULD be applying a
> SHOULD on this document to 8520 so that there is no IPR
> confusion.  And that implies an update.

[Med] It is fine to mandate that when 8520 is supported, this extension SHOULD 
be supported. But again, that is not updating 8520. 

So, unless you include such normative statement as part of the module I don't 
see the need to maintain the note about normative language in the description.

...
> 
> >
> > (5)
> >
> > Rather than using "leaf-list owners", I would define this as a list
> keyed by owners and which may include a leaf-list of licenses. Rather
> than defining license as a choice, I would use a "union".
> We're still discussing the substance of this.

[Med] Where this discussion is happening? 

> > (6)
> >
> > OLD:
> >
> >         "ol": {
> >           "owners": [
> >             "Copyright (c) FrobMaster 2021. All Rights Reserved"
> >           ],
> >           "spdx-tag": "0BSD"
> >         },
> >
> > NEW:
> >         "ietf-ol:ol": {
> >           "owners": [
> >             "Copyright (c) FrobMaster 2021. All Rights Reserved"
> >           ],
> >           "spdx-tag": "0BSD"
> >         },
> Still working on this.

[Med] Sorry, but I don't get your comment. "ol" should be prefixed with the 
name of the extension as this is different from the parent one. Please check 
Section 4 of RFC7951.

> > (7) Please update the IANA section as follows:
> >
> > OLD:
> >     The IANA is requested to add "ol" to the MUD extensions
> registry as
> >     follows:
> >
> >       Extension Name: ol
> >       Standard reference: This document
> >
> > NEW:
> >     The IANA is requested the following entry to the MUD extensions
> registry
> >     available at:
> https://www.iana.org/assignments/mud/mud.xhtml#mud-extensions
> >
> >       Extension Name: ol
> >       Reference: This document
> Done.  Thanks.
> > (8) Please update the IANA section with the following:
> >
> > NEW
> >
> >     This document requests IANA to register the following URI in
> the "ns"
> >     subregistry within the "IETF XML Registry" [RFC3688]:
> >
> >           URI: urn:ietf:params:xml:ns:yang:ietf-ol
> >           Registrant Contact: The IESG.
> >           XML: N/A; the requested URI is an XML namespace.
> >
> >     This document requests IANA to register the following YANG
> module in
> >     the "YANG Module Names" subregistry [RFC6020] within the "YANG
> >     Parameters" registry.
> >
> >           name: ietf-ol
> >           namespace: urn:ietf:params:xml:ns:yang:ietf-ol
> >           maintained by IANA: N
> >           prefix: ol
> >           reference: RFC XXXX
> What does "maintained by IANA" mean in this context?

[Med] This is whether the module will be updated by IANA, e.g., to reflect 
changes in some IANA-maintained registries. This is not the case for your 
draft. 


_________________________________________________________________________________________________________________________

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.

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to