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

"BRUNGARD, DEBORAH A" <> Tue, 27 November 2018 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E53D12D4ED for <>; Tue, 27 Nov 2018 14:09:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VG0Kz3HZgqMH for <>; Tue, 27 Nov 2018 14:09:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E760912870E for <>; Tue, 27 Nov 2018 14:09:44 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id wARM7PHC026166; Tue, 27 Nov 2018 17:09:40 -0500
Received: from ( []) by with ESMTP id 2p1d7mjh25-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Nov 2018 17:09:39 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id wARM9ctQ031872; Tue, 27 Nov 2018 17:09:38 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id wARM9X40031773; Tue, 27 Nov 2018 17:09:33 -0500
Received: from ( []) by (Service) with ESMTP id B927A40F6CEB; Tue, 27 Nov 2018 22:09:33 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id 9EE7F40F6CE4; Tue, 27 Nov 2018 22:09:33 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Tue, 27 Nov 2018 17:09:33 -0500
To: tom petch <>, Jonas Ahlberg <>, "" <>
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mw-yang-12.txt
Thread-Index: AQHUd9yOkosbCgHAPkCBI4GPsGxGr6VkRwuA
Date: Tue, 27 Nov 2018 22:09:32 +0000
Message-ID: <>
References: <> <> <01b701d47852$56406860$> <> <040e01d47b3a$f62ab2a0$>
In-Reply-To: <040e01d47b3a$f62ab2a0$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-27_18:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811270184
Archived-At: <>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mw-yang-12.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Nov 2018 22:09:48 -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!

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

----- Original Message -----
From: "Jonas Ahlberg" <>;
To: "tom petch" <>;; <>;
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.


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


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

----- Original Message -----
From: "Jonas Ahlberg" <>;
To: <>;
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.


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 <>; On Behalf Of
> Sent: den 9 november 2018 10:30
> To:
> Cc:
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-mw-yang-12.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> 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
>    the radio link interfaces, and their connectivity to packet
>    (typically Ethernet) interfaces in a microwave/millimeter wave
>    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
>    numbers and remove this note
> The IETF datatracker status page for this draft is:
> 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:
> 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=
> 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:
> 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
> Internet-Drafts are also available by anonymous FTP at:
> et-2Ddrafts_&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8
> w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3grwTRfIdC5gslok&s=PF8OQ0dhIIQkD3fkNwbb
> PuPabFH7jZZmsKa6AjclejA&e=
> _______________________________________________
> CCAMP mailing list
> man_listinfo_ccamp&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7j
> YlxXD8w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3grwTRfIdC5gslok&s=ajgWFSULbGc-EW
> hBuzcHFQlIgrKbzacrYzNPPT1GmXI&e=
> _______________________________________________
> CCAMP mailing list
> man_listinfo_ccamp&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7j
> YlxXD8w&m=Bm7sObKPz97dzt_aG7dZuh8YsYR3grwTRfIdC5gslok&s=ajgWFSULbGc-EW
> hBuzcHFQlIgrKbzacrYzNPPT1GmXI&e=

CCAMP mailing list