Hi Tom,
Sorry for being late but I have been struggling to understand what is your concern and therefore to understand how to move forward on this issue.
Since I have not seen further comments, I am trying a second attempt.
It looks like you do not like using the term te at least for OTN, WSON and Flexi-grid modules' prefixes. I am not sure we can remove the it from the MPLS-TE and ETH-TE to avoid potential conflicts with MPLS and ETH non-TE cases.
Could you please help me to understand which is your preferred option to move forward among the four below?
1) keep the current prefixes
2) change the prefixes as per my initial proposal
| TE | OTN | WSON | Flexi-Grid | ETH-TE | MPLS-TE | |
| Topology | tet | tet-otn | tet-wson | tet-flexig | tet-eth | tet-mpls |
| Tunnel | te | te-otn | te-wson | te-flexig | te-eth | te-mpls |
| Path Computation | tep | tep-otn | tep-wson | tep-flexig | tep-eth | tep-mpls |
3) change as per this updated proposal
| TE | OTN | WSON | Flexi-Grid | ETH-TE | MPLS-TE | |
| Topology | tet | otnt | wsont | flexigt | tet-eth | tet-mpls |
| Tunnel | tetu | otntu | wsontu | flexigtu | tetu-eth | tetu-mpls |
| Path Computation | tep | otnp | wsonp | flexigp | tep-eth | tep-mpls |
4) change as per your proposal (please fill in the table above)
| TE | OTN | WSON | Flexi-Grid | ETH-TE | MPLS-TE | |
| Topology | tet | |||||
| Tunnel | ||||||
| Path Computation |
Thanks, Italo
> -----Original Message-----
> From: tom petch [mailto:ietfc@xxxxxxxxxxxxx]
> Sent: giovedì 12 novembre 2020 12:38
> To: Italo Busi <Italo.Busi@xxxxxxxxxx>; Daniele Ceccarelli
> <daniele.ceccarelli@xxxxxxxxxxxx>; 'teas@xxxxxxxx' <teas@xxxxxxxx>;
> ccamp@xxxxxxxx
> Cc: draft-ietf-ccamp-otn-topo-yang.all@xxxxxxxx; yang-doctors@xxxxxxxx; last-
> call@xxxxxxxx
> Subject: Re: Common rules for TE-related YANG modules prefixes (was
> Yangdoctors last call review of draft-ietf-ccamp-otn-topo-yang-11)
>
> From: Italo Busi <Italo.Busi@xxxxxxxxxx>
> Sent: 05 November 2020 18:07
>
> Hi Tom,
>
> I am not sure whether you are saying:
>
> 1) having a common rule for TE-related YANG modules prefixes DOES NOT
> make sense unless we define common rule for all YANG modules prefixes
>
> 2) having a common rule for TE-related YANG modules prefixes make sense,
> but it would be even better if we define common rules for all YANG modules
> prefixes
>
> <tp>
> None of the above. I am saying that the world does not revolve around TE for
> many, perhaps most, people so classifying everything as an adjunct to TE is
> unhelpful.
>
> CCAMP deals in mw, WSON, flexigrid, otn, dwdm etc. and I see prefixes derived
> from them as being more helpful.
>
> I also see repeated efforts to use an identifier to encode semantic information
> thus rendering it a poor choice as an identifier. Identifiers need to be unique,
> easy to use not the source of semantics about what identity they are referring
> to. YANG Guidelines gets it right but might have gone a bit further.
>
> WSON gets it wrong IMHO. wson-yang uses wson as if there will never be
> anything else wson. wson-tunnel fails to register a prefix but does use wson-
> tunnel which is too long. wsont would be a poor choice as ...t is widely used for
> types and other common definitions. wson-iv has yet to get a YANG module
> but wsoniv might make sense. In 10 years time, how many WSON modules
> will there be? I do not know but suspect that there will be several and would
> like them to be wson... not viewed through the prism of a different axis.
>
> I think that the approach often adopted in IETF WG militates against good
> choices, in identifiers and in protocols, a tendency to get something out of the
> door after which it is on to the next step and oh dear, if only we had thought
> of the next step sooner then we could have allowed for it in the base instead
> of having to create a hack. (Amongst protocols MPLS is perhaps among the
> worse for failing to consider encoding the next protocol in its structures. but
> there are plenty of instances where no consideration is given to the probability
> of there being a second version and so no way of telling which is which
> although NETCONF showed a lack of foresight in putting supported modules in
> the initial exchange).
>
> So think beyond the next IESG review, where will we be in five or ten years,
> what will be helpful in reminding users what this is about, and keep it short.
>
> Tom Petch
>
> I am not sure whether it would be really feasible to come up with common
> rules for ALL YANG modules prefixes (at least I am not able to think about a
> proposal, at least because I do not have full visibility on all the YANG models to
> be considered). What would be your proposal?
>
> Thanks, Italo
>
> -----Original Message-----
> From: tom petch [mailto:ietfc@xxxxxxxxxxxxx]
> Sent: lunedì 2 novembre 2020 10:56
>
> From: Daniele Ceccarelli <daniele.ceccarelli@xxxxxxxxxxxx>
> Sent: 21 October 2020 11:15
>
> Hi,
>
> I think it's a good idea.
> Changing the naming for the WSON documents is not a problem, that can be
> done at the RFC editor stage.
>
> Tom, regarding you comment I would say that all the modules that the
> authors are referring to are TE based .Even if it's a multidimensional issue I
> would say we can use TE as the leading dimension.
>
> <tp>
> We can and for those whose world revolves around TE it might be useful but
> there is more to running a network than TE (shock, horror) and so an
> alternative dimension would be more useful - well it would for me. Should
> RSVP-TE be renamed TE-RSVP in all our documents?
>
> Tom Petch
>
> BR
> Daniele
>
>
>
> -----Original Message-----
> From: tom petch <ietfc@xxxxxxxxxxxxx>
> Sent: den 21 oktober 2020 11:33
> To: Italo Busi <Italo.Busi@xxxxxxxxxx>; 'teas@xxxxxxxx' <teas@xxxxxxxx>;
> call@xxxxxxxx
> Subject: Re: Common rules for TE-related YANG modules prefixes (was
> Yangdoctors last call review of draft-ietf-ccamp-otn-topo-yang-11)
>
> From: CCAMP <ccamp-bounces@xxxxxxxx> on behalf of Italo Busi
> Sent: 21 October 2020 09:26
> To: 'teas@xxxxxxxx'; ccamp@xxxxxxxx
>
> Hi all,
>
> We have got a YANG doctor review comment on OTN topology YANG model
> advocating that "modules from a common group could use some common and
> obvious rules for prefixes" (see mail below).
>
> While the comment seems reasonable to us, we have noted that, up to now,
> there are no such rules, as summarized in this table:
>
> <tp>
> There are no such rules, as in YANG Guidelines, but it is a good idea, probably
> taken as read by those who have been around the block a few times and have
> had to live with the (lack of) naming conventions in older management
> software, and incorporated automatically by such; and it has been regularly
> commented on by those reviewing YANG modules. I have made such
> comments recently on BGP and on NSF modules.
>
> But it should be noted that this is a multidimensional issue whereas the
> suggested changes below only take traffic engineering into account, as if that
> was the only attribute that matters. I think this wrong. Thus which matters
> more, that modules have traffic engineering in common or that they have e.g.
> WSON in common? I think that latter matters more in making it easier for
> users to understand so no, nothing else should start with te. Note too that
> there is often a separate types module and many such use a suffix of the letter
> 't' for this so having 'tet' somewhere in the string I also think likely to confuse.
>
> Tom Petch
>
> TE OTN WSON Flexi-Grid ETH-TE MPLS-TE
> Topology tet otntopo wson flexi-grid ethtetopo tet-mpls
> Tunnel te otn-tunnel wson-tunnel flexi-grid-media-channel eth-
> tunnel te-mpls
> Path Computation te-pc
>
> In order to have such common rules, the prefixes could be changed as:
>
> TE OTN WSON Flexi-Grid ETH-TE MPLS-TE
> Topology tet tet-otn tet-wson tet-flexig tet-eth tet-mpls
> Tunnel te te-otn te-wson te-flexig te-eth te-mpls
> Path Computation tep tep-otn tep-wson tep-flexig tep-eth tep-
> mpls
>
> It is worth noting that
>
> * the prefix used by TE topology cannot be changed since it has been
> already published as RFC8795
> * we do not know whether we can change the prefix for the WSON topology
> since the draft has already passed IETF Last Call (our assumption is that this
> would still be possible)
>
>
> We would like to gather CCAMP and TEAS WGs opinion about whether:
>
>
> 1. Having common rules for TE YANG modules is valuable
> 2. The proposed prefixes are acceptable
>
>
> Aihua, Haomian and Italo (on behalf of co-authors)
>
> -----Original Message-----
> From: Radek Krejčí via Datatracker [mailto:noreply@xxxxxxxx]
> Sent: venerdì 16 ottobre 2020 15:33
> To: yang-doctors@xxxxxxxx
> call@xxxxxxxx
> Subject: Yangdoctors last call review of draft-ietf-ccamp-otn-topo-yang-11
>
> Reviewer: Radek Krejčí
> Review result: Ready with Issues
>
> This is my yang doctor review of draft draft-ietf-ccamp-otn-topo-yang-11 with
> the ietf-otn-topology@2020-09-21 YANG module.
>
> Despite the size of the module, its structure is very simple repeatedly following
> a pattern of augmenting ietf-te-topology by groupings defined in ietf-layer1-
> types module.
>
> Datatracker's validation with yanglint reports a number of warnings, but they
> are false positive (fixed in yanglint 1.9.16 - the fixed version still reports
> warnings, but they are all from the imported ietf-layer1-type module).
>
> My only note to the module itself is about the two defined groupings - I'm not
> sure about the reusability of the groupings in other modules. If the reusability
> is not the concern, I don't see any reason to define them.
>
> Regarding the draft, as a reader, I would appreciate a more targeted
> description in section 3. Instead of just dumping the tree diagram in section
> 3.2, it would be useful to split it into several areas with some brief descriptions
> and examples.
>
> The list of paths is introduced in Section 6 as "the subtrees and data nodes and
> their sensitivity/vulnerability", but I don't see explained/described the
> mentioned sensitivity/vulnerability of those paths.
>
> The prefix of the YANG module (also referred to in Section 7 ) - 'otntopo' -
> seems inconsistent to me. The relevant ietf-te-topology has 'tet' (so I would
> expect 'otnt' here), on the other hand, the ietf-otn-tunnel has 'otn-tunnel'
> prefix (then I would expect 'otn-topo' prefix here). The 'otntopo' seems to
> introduce just another format. As a reader/user, I would prefer if the modules
> from a common group could use some common and obvious rules for prefixes.
>
>
>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
