Re: [TICTOC] Yangdoctors early review of draft-ietf-tictoc-1588v2-yang-10

Radek Krejčí <rkrejci@cesnet.cz> Mon, 29 October 2018 08:58 UTC

Return-Path: <rkrejci@cesnet.cz>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9EC12D4EC; Mon, 29 Oct 2018 01:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.32
X-Spam-Level:
X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq0bO7Z5NlP1; Mon, 29 Oct 2018 01:58:14 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4105512DDA3; Mon, 29 Oct 2018 01:58:13 -0700 (PDT)
Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:64e:1f1d:a677:2dc8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 83DBF40005D; Mon, 29 Oct 2018 09:58:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1540803490; bh=lDzLyENzVxtDAvDpTkel5chHc4Ww13z6gLABw9P3mOs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=CA27boOaHjAzLTODDcoJ3i+D0cqGor7m7vXkt1imoaE7450Ib6YmYLnentvK0Q0T7 gD467QBdSnb8e44pKugQJCzxThTzZPlgB9rkyT9s+lMs2E6/xNkAno3aIZq83ry4GZ UKmH44Ql9OT20wGkRAwbnaHP8HtA0nNUeHNg/sYA=
To: Jiangyuanlong <jiangyuanlong@huawei.com>, Alex Campbell <Alex.Campbell@Aviatnet.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Cc: "draft-ietf-tictoc-1588v2-yang.all@ietf.org" <draft-ietf-tictoc-1588v2-yang.all@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>
References: <154045022283.6867.1264697701888740594@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBC23ED62@dggeml512-mbx.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBC23EFD5@dggeml512-mbx.china.huawei.com> <054e520b-ca22-5b96-24cb-d78ff7926742@cesnet.cz> <3B0A1BED22CAD649A1B3E97BE5DDD68BBC240353@dggeml512-mbx.china.huawei.com> <88bc64f4-1d7b-a273-1100-91b9bc770315@cesnet.cz> <1540764390228.23487@Aviatnet.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBC24191E@dggeml512-mbx.china.huawei.com>
From: Radek Krejčí <rkrejci@cesnet.cz>
Openpgp: preference=signencrypt
Autocrypt: addr=rkrejci@cesnet.cz; prefer-encrypt=mutual; keydata= xsDiBEKfHd4RBADDE8CtJpEtOraXBKfQg0KCRZu7BRALixoLqW98U+N9h+PJ+gCnFaKNmnYu fXWLYKTJRUlaoMGIJOZjHpr/zvwozSR+VJkxCsTyNYTF8vIfN3Iwrxy9e8CNy/O1GI50K/ld WWMDl+3M2NztiBFPrCT0b/U5ErsN7bTrf2XLEQRpZwCg95POGbJPqPAaaok2KU5e2u0/flsD /AyC0aRO66Ci0OGw0R5sCJmzZ5xE5eBUvfx0N0IC16aojrwRYM5yf+bULtBDd4wPI1R+VH/X P6OrDgzlDmutJthVtYfCcho3IhqnVo1R/UvJxjF3ATKbOnVHL4xwiLSrRDb6rKVyd1+Kc7cq +JABgFl+JP4xndytvvUXdVqhuSUFBACCDdDtxutkclBrvEp2guBIftuT4/oK3IWxgtevlGfY LZXwdD6pIWS1z6y6xthoFTsLWS1QCFk2ZXmAgvOV/lnW0iGHwO5kCfzvWJq7weeH2FGuBgq+ WInxhdIFD/QwiXV6EPUWzAoC5Fx4Cz5ySFSd6n0C1Mrzin3ABtPHRpUT8s0pUmFkZWsgS3Jl amNpIChDRVNORVQpIDxya3JlamNpQGNlc25ldC5jej7CYgQTEQIAIgUCTT/pkAIbAwYLCQgH AwIGFQgCCQoLBBYCAwECHgECF4AACgkQIMoxClN+p/31DwCfWVWX1IWaUa6+QbuVvZQIkb6m Rn8AoLRvdANGe/As/Nxabu+KKtrorkQ6zsBNBEKfHeIQBACwORs231u+o9/pM7y85ZlZhnNY iJziZ4P5W9lD5cwcEUFgTt1upUmjjSMWr5x4HL6o5jZeKOQMxiYP+8qA8OPEM6fzemS1Uj9M 6RXUaoUZFrcKD6BvneyyKuGgNa9bQfTG0aDOqaxy4lYFNcHVeo9sXJ+6adVxlCo/GzZ6zznn nwADBQP+IZQoao7aCFkZOVk8F5AW9Iiz0hk1trdCw88vD5fPMqcLxOQEsKrHAjibTWyOy1il 9zgLyVjcBzOs+v6UvbcJRybyaITC7j4IFPr78euVup/AeL+A9ay+ZWKHMFzALD+VjLyYAiRL w2MBjdqAKbPh2Ei1HXJoOX5JTWWnMRsBey/CSQQYEQIACQUCQp8d4gIbDAAKCRAgyjEKU36n /YssAKDVrEroZMSci018ipG4q6w11TsriwCghwCwX0isavqXJTbw10hwJePlDns=
Message-ID: <883198c7-cb4c-11d8-109a-abb3d93b7638@cesnet.cz>
Date: Mon, 29 Oct 2018 09:58:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBC24191E@dggeml512-mbx.china.huawei.com>
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/x6XBWcHVV0ID0N3Nqyr-USnsOUY>
Subject: Re: [TICTOC] Yangdoctors early review of draft-ietf-tictoc-1588v2-yang-10
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2018 08:58:18 -0000

I agree. The reason of the statement in RFC7950 is to increase human readability of the YANG modules. It has nothing to do with technical limitations of YANG implementations - 1) the scope of the prefix is only for the importing module itself (it is not the XML prefix used for data) and 2) implementations must be prepared for the case of prefix collision when it cannot be the same as the prefix of the imported module.

I believe that both mentioned ways are fine, but the second one is better.

Regards,
Radek

Dne 29. 10. 18 v 9:27 Jiangyuanlong napsal(a):
> Hi Alex, 
>
> We all agree with what Radek's said. The issue is, what shall we include in the appendix A.3 of this document?
> There are two options in consideration:
> 1. admit that ieee1588-ptp could specify whatever prefix, such as "ieee1588" prefix, and other modules in migration can import it using the original "ptp" prefix. 
> In this case, we don't need to say anything on the prefix of ieee1588 YANG as there is no suggestion on it. As a result, we can remove the whole paragraph.
> However, a totally new module importing ieee1588-ptp will most likely use the new default import prefix "ieee1588", thus implementations will diverge along the road (i.e., some use "ptp", and some use "ieee1588" as in the example).
>
> 2. suggest that ieee1588-ptp still use the same "ptp" prefix, and other modules in migration can still import it using the original "ptp" prefix.
> In this case, a totally new module importing ieee1588-ptp will most likely use the default import prefix "ptp", thus it is consistent with the above migration case.
> This is also aligned with the statement in RFC7950 that "the prefix defined by a module SHOULD be used when the module is imported".
>
> It seems to me option 2 is slightly better. But I will be glad to see more opinions on this topic.
>
> Thanks,
> Yuanlong
>
> -----Original Message-----
> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com] 
> Sent: Monday, October 29, 2018 6:07 AM
> To: Radek Krejčí <rkrejci@cesnet.cz>; Jiangyuanlong <jiangyuanlong@huawei.com>; yang-doctors@ietf.org
> Cc: draft-ietf-tictoc-1588v2-yang.all@ietf.org; tictoc@ietf.org
> Subject: Re: [TICTOC] Yangdoctors early review of draft-ietf-tictoc-1588v2-yang-10
>
> Radek's original comment still seems to apply here.
>
> Other modules can import this module using whatever prefix they like.
> It doesn't have to be the same as the one defined in the module - that is just a convention to minimize any potential confusion.
>
> ieee1588-ptp could specify a "ieee1588" prefix, for example, and other modules would still be free to import it using the "ptp" prefix.
>
> ________________________________________
> From: TICTOC <tictoc-bounces@ietf.org> on behalf of Radek Krejčí <rkrejci@cesnet.cz>
> Sent: Friday, 26 October 2018 7:59 p.m.
> To: Jiangyuanlong; yang-doctors@ietf.org
> Cc: draft-ietf-tictoc-1588v2-yang.all@ietf.org; tictoc@ietf.org
> Subject: Re: [TICTOC] Yangdoctors early review of draft-ietf-tictoc-1588v2-yang-10
>
> Hi Yuanlong,
> just a minor change:
>
>    Under the assumptions of section A.1, the first IEEE 1588 YANG
>    module's prefix will be the same as the last IETF 1588 YANG module's
>    prefix (i.e. "ptp"). Consequently, other YANG modules can preserve
>    the same import prefix "ptp" to access PTP nodes during the migration
>    from the last IETF 1588 YANG module to the first IEEE 1588 YANG module.
>
> What do you think?
>
> Regards,
> Radek
>
>
>
> Dne 26. 10. 18 v 5:34 Jiangyuanlong napsal(a):
>> Dear Radek,
>>
>> Thanks for the clarification and the good suggestion. Yes, your capture is right, and your texts are also correct basically. Though I think the focus in the texts is "other YANG modules", not a target for our standardization.
>>
>> To emphasize that the first IEEE 1588 YANG is the primary subject, how about rephrase your texts into the following new texts?
>> NEW
>>
>>    Under the assumptions of section A.1, the first IEEE 1588 YANG
>>    module's prefix will be the same as the last IETF 1588 YANG module's
>>    prefix (i.e. "ptp"). Consequently, it is convenient for other YANG
>>    modules to use the same default module prefix "ptp" to access PTP
>>    nodes during the migration from the last IETF 1588 YANG module to
>>    the first IEEE 1588 YANG module.
>>
>> Any concerns or other suggestions?
>>
>> Kind regards,
>> Yuanlong
>>
>> -----Original Message-----
>> From: Radek Krejčí [mailto:rkrejci@cesnet.cz]
>> Sent: Thursday, October 25, 2018 10:16 PM
>> To: Jiangyuanlong <jiangyuanlong@huawei.com>; yang-doctors@ietf.org
>> Cc: draft-ietf-tictoc-1588v2-yang.all@ietf.org; tictoc@ietf.org
>> Subject: Re: Yangdoctors early review of draft-ietf-tictoc-1588v2-yang-10
>>
>> Hi Yuanlong,
>> let me clarify it - so, we are talking about the YANG module's prefix, right? And "used by other PTP applications" means imported in some other YANG module, right? Then the prefix connected with such an import is arbitrary and it is scoped only to the YANG module where the ptp module is imported. So even if the prefix in the ptp module changes, the modules which imports ptp module does not need to change the prefix they use for the ptp import. I agree, that it is always better when the prefixes matches (and yes, RFC says SHOULD be the same), I'm just saying that it is not a problem when they don't (implementation must be able to handle it because of possible collisions).
>>
>> The reason why the text seems weird to me is because it does not make sense to me that preserving the prefix is possible because (this is how I understand the paragraph, maybe wrongly) the nodes within the modules are compatible. RFC 7950 allow me to change or preserve the prefix despite the compatibility of the nodes. So what about the following text?
>>
>> OLD
>>
>>    Under the assumptions of section A.1, the first IEEE 1588 YANG
>>    module prefix can be the same as the last IETF 1588 YANG module
>>    prefix (i.e. "ptp"), since the nodes within both YANG modules are
>>    compatible.
>>
>> NEW
>>
>>    Under the assumptions of section A.1, it will be useful and
>>    convenient for other YANG modules using 1588 YANG module to keep
>>    the module prefix of the first IEEE 1588 YANG modules same as in
>>    the last IETF 1588 YANG module (i.e. "ptp").
>>
>> Regards,
>> Radek
>>
>>
>>
>> Dne 25. 10. 18 v 11:08 Jiangyuanlong napsal(a):
>>> Radek,
>>>
>>> Sorry that my 2nd comment is not correct.
>>> The module's prefix, i.e., "ptp", is used by other PTP applications (according to RFC7950, the prefix defined by a module SHOULD be used when the module is imported).
>>> If the same prefix "ptp" is used, these PTP applications don't need to change their YANG codes (i.e., always use the same prefix "ptp" to access PTP nodes), but only change a URN namespace when migrating from IETF to IEEE-1588.
>>> Thus it is more convenient for an implementation to migrate from IETF 1588 YANG to IEEE 1588 YANG.
>>> Since the IETF will transfer the development work of the 1588 YANG to IEEE-1588, it is unlikely that another new 1588 YANG module's prefix will be introduced in the IETF.
>>>
>>> Do you have any suggestions to improve the texts?
>>>
>>> Thanks,
>>> Yuanlong
>>>
>>> -----Original Message-----
>>> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Jiangyuanlong
>>> Sent: Thursday, October 25, 2018 4:20 PM
>>> To: Radek Krejčí <rkrejci@cesnet.cz>; yang-doctors@ietf.org
>>> Cc: draft-ietf-tictoc-1588v2-yang.all@ietf.org; tictoc@ietf.org
>>> Subject: Re: [TICTOC] Yangdoctors early review of draft-ietf-tictoc-1588v2-yang-10
>>>
>>> Hi Radek,
>>>
>>> Thanks much for the review.
>>> Please see my comments in the line.
>>>
>>> Best regards,
>>> Yuanlong
>>>
>>> -----Original Message-----
>>> From: Radek Krejčí [mailto:rkrejci@cesnet.cz]
>>> Sent: Thursday, October 25, 2018 2:50 PM
>>> To: yang-doctors@ietf.org
>>> Cc: draft-ietf-tictoc-1588v2-yang.all@ietf.org; tictoc@ietf.org
>>> Subject: Yangdoctors early review of draft-ietf-tictoc-1588v2-yang-10
>>>
>>> Reviewer: Radek Krejčí
>>> Review result: Ready with Nits
>>>
>>> This is my YANG-doctor review of draft-ietf-tictoc-1588v2-yang-10. I have reviewed it mainly from the YANG perspective, since I'm not familiar with IEEE 1588.
>>>
>>> The draft as well as the YANG module ietf-ptp@2018-09-10 are in a good shape and ready to publish. I have only 2, say, editorial notes.
>>>
>>> 1) email of Rodney Cummings in the module's contact statement misses (in contrast to emails of other authors) starting ('<') and ending ('>') tags.
>>> [YJ] Good catch, I found this inconsistence too, and we will update it in the next revision.
>>>
>>> 2) I don't see any reason for the following paragraph in the appendix A3:
>>>
>>>    Under the assumptions of section A.1, the first IEEE 1588 YANG
>>>    module prefix can be the same as the last IETF 1588 YANG module
>>>    prefix (i.e. "ptp"), since the nodes within both YANG modules are
>>>    compatible.
>>>
>>> Since the module's prefix is used only locally, it may change when the module is updated (RFC 7950, sec. 11). So the mentioned paragraph seems pointless to me (and therefore confusing for readers).
>>> [YJ] Good catch, there is a misspelling here, "prefix" should be "postfix" in A.3, it is not the "prefix" statement in the YANG. The logic is, both "ieee1588-ptp" and "ietf-ptp" have a "ptp" postfix.
>>>
>>> _______________________________________________
>>> TICTOC mailing list
>>> TICTOC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tictoc
>>>
>
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc