Re: [CCAMP] I-D Action: draft-ietf-ccamp-mw-yang-12.txt

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi Tom,

Much thanks for all your help on this. It's not the first time the IANA section changes late in the process, what is needed is for their review and approval. In this case, IANA asked me to wait before approving so they can sort out.

Authors (Jonas), update the document to reflect as Tom says to be accurate. We can always respin again if needed based on IANA feedback.

Again thanks!
Deborah


-----Original Message-----
From: CCAMP <[e-mail]> On Behalf Of tom petch
Sent: Tuesday, November 13, 2018 5:26 AM
To: Jonas Ahlberg <[e-mail]>; [e-mail]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mw-yang-12.txt

----- Original Message -----
From: "Jonas Ahlberg" <[e-mail]>
To: "tom petch" <[e-mail]>; <[e-mail]>
Sent: Sunday, November 11, 2018 10:51 AM

Hi Tom,

Yes, you are perfectly correct!

We talked to IANA representatives on Thursday last week at IETF 103 and they helped us to apply for two new IANA IfTypes, with the purpose to get them registered as ifType definitions in [IANA registry smi-numbers].
I think we have followed the correct procedure, but I have described it incorrectly in the updated draft where I reference RFC7224.

We also understand that this is a change very late in the process, so before going ahead with it we talked to and got an OK from Deborah (responsible AD).

One question is now what to do about the incorrect description of the IANA request in the draft. Should I update it right away, reach out to IANA or wait for a formal response from them before doing an update.

<tp>

Like I said,  more work for the AD to sort out.  My take would be that IANA Considerations gets changed anyway, e.g. from 'It is proposed that IANA ..' to 'IANA has updated ... ', so I would not see a problem with changing the text to more accurately reflect the process, essentially dropping the " YANG Module" [RFC7224] ".

I would not issue a new I-D unless or until the AD says so.

It would be good to have changed text in the RFC so as not to mislead those coming after, but I am sure the IETF will cope even if it is not changed.

Tom Petch

Regards
JonasA


 -----Original Message-----
From: tom petch <[e-mail]>
Sent: den 9 november 2018 18:35
To: Jonas Ahlberg <[e-mail]>; [e-mail]

----- Original Message -----
From: "Jonas Ahlberg" <[e-mail]>
To: <[e-mail]>
Sent: Friday, November 09, 2018 3:37 AM

> As Amy explained in an earlier mail, this a minor update of
draft-ietf-ccamp-mw-yang where we have asked IANA to register new IANAifTypes for the interface types radio-link-terminal and carrier-termination in the "IANA Interface Type YANG Module" [RFC7224], instead of defining them locally in the ietf-microwave-types module.

Jonas

That is not right - in fact, it is wrong.  RFC7224 provided the initial contents of the YANG module and as the IANA website says,

Interface types must not be directly added to the iana-if-type YANG module. They must instead be added to the "ifType definitions" registry at [IANA registry smi-numbers].

after which, IANA updates the IANA-maintained MIB module and the IANA-maintained YANG module.

Your request should be for the registration of an ifType definition (which dates back to RFC1213) which, if the Designated Expert approves, will result in both IANA-maintained modules being updated.

And the request for registration can be made in any suitable way to IANA - an e-mail does fine - as long as there is a stable definition for the Designated Expert to examine.  So, no need to re-issue the I-D.

However, what is done is done and I trust IANA to read between the lines and do what is wanted even if the IANA Considerations in the latest I-D are not quite what they might be.  One problem to which I do not know the
answer:-) is what happens with the I-D changing after the IESG have approved it n earlier version  - never a good idea, but more work for the AD to sort:-(

Question is, are we going to go through all this effort all over again for such as TEAS and MPLS?  My guess would be yes:-(.

Tom Petch

> Regards
> JonasA
>
> -----Original Message-----
> From: CCAMP <[e-mail]> On Behalf Of
[e-mail]
> Sent: den 9 november 2018 10:30
> To: [e-mail]
> Cc: [e-mail]
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-mw-yang-12.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Common Control and Measurement Plane
WG of the IETF.
>
>         Title           : A YANG Data Model for Microwave Radio Link
>         Authors         : Jonas Ahlberg
>                           Ye Min
>                           Xi Li
>                           Daniela Spreafico
>                           Marko Vaupotic
> Filename        : draft-ietf-ccamp-mw-yang-12.txt
> Pages           : 51
> Date            : 2018-11-08
>
> Abstract:
>    This document defines a YANG data model for control and management
of
>    the radio link interfaces, and their connectivity to packet
>    (typically Ethernet) interfaces in a microwave/millimeter wave
node.
>    The data nodes for management of the interface protection
>    functionality is broken out into a separate and generic YANG data
>    model in order to make it available also for other interface types.
>
> RFC Ed.  Note
>
>    // RFC Ed.: replace all XXXX throughout the document with actual
RFC
>    numbers and remove this note
>
>
> The IETF datatracker status page for this draft is:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_doc_draft-2Dietf-2Dccamp-2Dmw-2Dyang_&d=DwICAg&c=LFYZ-o9_HUMeMTSQi
> cvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3grwTRfIdC
> 5gslok&s=RW_BVePKpIsLzciNR4xk-MC2LIpyUbIsOGkMKIbUSew&e=
>
> There are also htmlized versions available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> ml_draft-2Dietf-2Dccamp-2Dmw-2Dyang-2D12&d=DwICAg&c=LFYZ-o9_HUMeMTSQic
> vjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3grwTRfIdC5
> gslok&s=zJShJh-McYWkI6B8NVhVdT-fAhR6Me3O9RPUigqY2q4&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_doc_html_draft-2Dietf-2Dccamp-2Dmw-2Dyang-2D12&d=DwICAg&c=LFYZ-o9_
> HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3
> grwTRfIdC5gslok&s=9XQFWi4f2DEkKV4bkaKKoIzS8gewYImwoEXKisjajdI&e=
>
> A diff from the previous version is available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcd
> iff-3Furl2-3Ddraft-2Dietf-2Dccamp-2Dmw-2Dyang-2D12&d=DwICAg&c=LFYZ-o9_
> HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3
> grwTRfIdC5gslok&s=NY4pSeE6EJ6iDb3ka6geN2CDimm6vP6liRWC2-JtFXI&e=
>
>
> Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_intern
> et-2Ddrafts_&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8
> w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3grwTRfIdC5gslok&s=PF8OQ0dhIIQkD3fkNwbb
> PuPabFH7jZZmsKa6AjclejA&e=
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ccamp&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7j
> YlxXD8w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3grwTRfIdC5gslok&s=ajgWFSULbGc-EW
> hBuzcHFQlIgrKbzacrYzNPPT1GmXI&e=
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ccamp&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7j
> YlxXD8w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3grwTRfIdC5gslok&s=ajgWFSULbGc-EW
> hBuzcHFQlIgrKbzacrYzNPPT1GmXI&e=

_______________________________________________
CCAMP mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ccamp&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3grwTRfIdC5gslok&s=ajgWFSULbGc-EWhBuzcHFQlIgrKbzacrYzNPPT1GmXI&e=