Re: Re: I-D Action: draft-ietf-rtgwg-policy-model-15

[t petch <[e-mail]>]

Looking some more, at -15:

The choice of OSPF identity puzzles me

I would expect a base OSPF identity to be useful from which all other 
OSPF then derive

I am not familiar with NSSA T1 and T2 - I see no such language in 
RFC3101 nor is there an update to that RFC (but they do appear in 
ospf-yang!)

The identity names seem inconsistent
       identity ospf-internal-type {
       identity ospf-external-type {
       identity ospf-external-t1 {
       identity ospf-external-t2-type {
       identity ospf-nssa-type {
       identity ospf-nssa-t1 {
I suspect that '-type' is redundant if the usage is as in this i-D

More generally, is the intention that these match the LSA type?  If so, 
it would help me to have the value of the LSA type in the YANG 
description - it is what I think in terms of.

s.10
'described by the YANG modules' !

"RFC 5302 - Domain-Wide Prefix Distributino ..."

       container routing-policy {
               leaf name {
                 type string;
I have always liked the more constrained yang-identifier as opposed to 
string but suspect I am alone in that.

  I did look for the four original authors and did not see them; they 
are there - I was looking at the second list of parties and missed the 
first list which is where they are


Tom Petch


> I have some doubts about this I-D
>
> -01 had four authors; -13 has four authors.  None are the same yet much
> of the text in the I-D is the same.
>
> NSSA could be added to the Terminology and/or expanded on first use.
>
> Policy subroutines sound interesting - if there is one example I would
> find useful it would be one involving subroutines.
>
> 10 YANG modules
> I only see one singular
>
> XXXX is used as a placeholder for two different I-D
>
> I like the reference to RFC2178, RFC5130 but they need to appear in the
> I-D References and more YANG reference clauses would not come amiss
>
>       typedef metric-modification-type {
> ....
>                   If the result would exceed the maximum metric
>                (0xffffffff), set the metric to the maximum.";
> OSPF has a 16 bit link metric, a 24 bit route metric as defined in
> ospg-yang.  Defining a maximum of 0xffffffff seems problematic. Add two
> to 16777215 and you get one.
> The other LSR protocol has a 6 or 24 or 32 bit metric depending on where
> you look.
>
>             "The prefix member in CIDR notation -- "
> member of what?  My prefix are a number!
>
>         leaf mask-length-upper {
> the example implies that upper and lower must both be present which I do
> not see in the YANG.  Both upper and lower are part of the YANG key of
> the list which also suggests that both need to be present
>
>       grouping match-proto-route-type-condition {
> gets a bit long; here and elsewhere, is 'proto' needed as part of the
> identifier?
>
>           container prefix-sets {
>               leaf mode {
> I am not a fan of features - Cartesian explosion - but wonder if one is
> called for here at least for mixed mode
>
> Tom Petch
>
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
>