haomianzheng
commented
1 year ago I agree with Nicolai about the ambiguity of P
This one is tentatively done by removing the P node in Figure 1.
RFC6991 is no longer an import but it is still present in several places.
The reference of RFC6991 is removed in both Table 1, and normative reference.
I love to keep pointing out that an unrestricted YANG string can be 18446744073709551615 characters long; will boxes be able to support this? will they be able to support YANG keys of this length?
No change made. I don't want to restrict this, to make the flexible usage of the model.
Is there a convention for how the ends are referenced? This has a mix of 'one' and 'other' with '-1' and '-2'
No change made. I think it's reasonable to have -1 and -2 in the model, but 'one' and 'other' in description. Tweak my English...
error message about the ids would be better as 'end point IDs'
Fixed, see https://github.com/haomianzheng/IETF-ACTN-YANG-Model/pull/124
uni access type could do with a reference; G.709?
We could have this, but need to understand the explicit places. My current understanding is referencing of 'uni-access-type', and we can have double referencing to ITU-T G.709 and MEF 63.
italobusi
Borrowing a suitable e-mail to respond to, there are a lot of changes from -17 to -19 and some new issues.
I agree with Nicolai about the ambiguity of P
RFC6991 is no longer an import but it is still present in several places.
I love to keep pointing out that an unrestricted YANG string can be 18446744073709551615 characters long; will boxes be able to support this? will they be able to support YANG keys of this length?
Is there a convention for how the ends are referenced? This has a mix of 'one' and 'other' with '-1' and '-2'
error message about the ids would be better as 'end point IDs'
uni access type could do with a reference; G.709?
Reference to: https://mailarchive.ietf.org/arch/msg/ccamp/trx-aKbxsaW0IgnTR61kLSn4uZM/