[netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    tte> https://trac.ietf.org/trac/netmod/wiki/YANG_FAQ#when-use-empty
    tte> Is this the solution we are looking for ?


here it the relevant text:

} The second situation is when you want to define an extensible enumeration,
} as an alternative to the type "enumeration", which is not extensible by other
} modules. For example if an enumeration is used:

} leaf protocol {
}   type enumeration {
}     enum smtp;
}     enum pop3;
}   }
} }
} and we want to add a new protocol 'imap4', it must be done by adding a new
} enum in the module. But if we use a choice of type empty instead:

} container protocol {
}   choice p {
}     case smtp { leaf smtp { type empty; } }
}     case pop3 { leaf pop3 { type empty; } }
}   }
} }
} then another module can augment the first:
}
} augment /foo:protocol/p {
}    case imap4 { leaf imap4 { type empty; } }
} }

Well, this seems to be exactly what we want.
Do we get to put a description in there?
can we put a value in so that our SID process works?
(I imagine we'll have to hack pyang to make it cope, but...)

proceedural options:

1) write this up as errata against 8366.  That seems a bit much for errata,
   but how much whisky does it cost to bribe an AD?

2) write a formal "Updates" RFC8366 that just does the NEW/OLD version of
   updates, and that's it.

3) do an entire RFC8366bis.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide