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

From: [email-masked]
Date: Thu, 08 Nov 2018 19:30:07 -0800

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://datatracker.ietf.org/doc/draft-ietf-ccamp-mw-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ccamp-mw-yang-12
https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-mw-yang-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mw-yang-12

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:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jonas Ahlberg <[email-masked]>
Date: Fri, 9 Nov 2018 03:37:56 +0000

Hi all,

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.

Regards
JonasA

-----Original Message-----
From: CCAMP <[email-masked]> On Behalf Of [email-masked]
Sent: den 9 november 2018 10:30
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-mw-yang-12.txt

Abstract:

RFC Ed.  Note

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.

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: tom petch <[email-masked]>
Date: Fri, 9 Nov 2018 17:35:10 +0000

----- Original Message -----
From: "Jonas Ahlberg" <[email-masked]>
To: <[email-masked]>
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

> 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.

---

From: Jonas Ahlberg <[email-masked]>
Date: Sun, 11 Nov 2018 10:51:21 +0000

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.

Regards
JonasA

 -----Original Message-----
From: tom petch <[email-masked]> 
Sent: den 9 november 2018 18:35
To: Jonas Ahlberg <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mw-yang-12.txt

----- Original Message -----
From: "Jonas Ahlberg" <[email-masked]>
To: <[email-masked]>
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

> 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.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 12 Nov 2018 11:42:22 +0000

Hi Jonas,

the draft is now in AD followup status, hence managed by Deborah.
You can agree offline with her on how to proceed. Probably a revised id is the best way.

BR
Daniele  

> From: CCAMP <[email-masked]> On Behalf Of Jonas Ahlberg
> Sent: domenica 11 novembre 2018 11:51
> To: tom petch <[email-masked]>; [email-masked]
> 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.
> 
> Regards
> JonasA
> 
> 
> 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].
> 
> Your request should be for the registration of an ifType definition (which
> dates back to RFC1213) which, if the Designated Expert approves, will result
> 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.
> 
> 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
> approved it n earlier version  - never a good idea, but more work for the AD
> to sort:-(
>

---

From: tom petch <[email-masked]>
Date: Tue, 13 Nov 2018 10:25:30 +0000

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

Hi Tom,

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 <[email-masked]>
Sent: den 9 november 2018 18:35
To: Jonas Ahlberg <[email-masked]>; [email-masked]

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

Jonas

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.

the AD to sort:-(

Tom Petch

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 27 Nov 2018 22:09:32 +0000

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 <[email-masked]> On Behalf Of tom petch
Sent: Tuesday, November 13, 2018 5:26 AM
To: Jonas Ahlberg <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mw-yang-12.txt

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

Hi Tom,

<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] ".

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 <[email-masked]>
Sent: den 9 november 2018 18:35
To: Jonas Ahlberg <[email-masked]>; [email-masked]

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

Jonas

Tom Petch

> 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=
>
> 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=
>
> 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=
>
>
> 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=
>
> 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=
>
> 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
[email-masked]
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=