Hi,

The new text works, but I'm not sure whether it should be included here. See 
[AB] inline.

> 1) Regarding "For example, authors of a module with such identifiers
> have to indicate...”, I’m unsure how the registrant is suppose to
> propose valid YANG identifiers.   First, I wonder if the registrant
> would even be aware of the existence of a YANG module for the
> underlying registry.   Next, I wonder if the registrant would know
> what are valid YANG identifier values.
> 
> [Med] Fully agree that the registrant of a new entry does not (and
> does not even need to) know the existence of the IANA-maintained
> module. The instruction here is not for those.
> 
> What I do know, because it happened to me, if that my using the
> underlying value caused a YANG error.   This is what I suspect will
> happen to IANA.   That is, they’ll first try the underlying value and
> get a module-validation error…
> 
> 
> Thus I wonder if the instructions should be more in the form of “do
> this when an error occurs”, instead of instructions that attempt to
> proactively determine the issues before they occur?
> 
> [Med] The proactive approach has the merit to ensure consistent naming
> conventions and straightforward actions for IANA. I think that we
> should encourage authors to look into this. There might be errors if
> the naming conventions listed in Section 4.3.1 are not followed. I
> have no problem to reword the text so that this can be easily consumed
> by IANA as well. I hope Amanda can share her feedback/preference.

[AB] I see how this advice would work if IANA were creating the module, but I'm 
a little less clear on how it works for anticipating future underlying 
registrations. 

If an identifier won't validate, IANA will already know that they have to take 
some action to remedy it. The first step would be to check whether the module 
had already solved the problem for an earlier occurrence of "3des-*". If there 
were no such existing registration, and knowing that "3" might be rendered as 
either "triple" or "three," instead of checking the RFC that created the module 
for advice about a string that didn't appear in the underlying registry at the 
time of publication, we would more likely ask the YANG doctors how to proceed. 
(If the underlying registry had designated experts, we might check with them 
first.)

If the authors for a specific module already know that there are that likely to 
be more "3des-*" registrations in the future, there's no harm in calling it out 
(as long as they don't appear to be implying that the "triple-" solution should 
be applied to any leading number), but in general, it might be better to give 
IANA advice about how to resolve identifier questions in general (e.g., check 
the existing module, contact the YANG doctors or other appropriate party). 

thanks,
Amanda

_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to