RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M4: IANAconsiderations)

[<[e-mail]>]

Robert,

>> M4. IANA consideration section
>> 
>> I think the IANA consideration section is lacking in several ways.
>> 
>> A. Decision criteria for IESG, Expert review or other 
>policies are not 
>> written. The WG should provide some guidelines for what is 
>acceptable 
>> to be registered and what is not.
>
>This is a document roadmap issue; there are several different 
>ways in which NSIS (as a protocol suite) can be extended to 
>meet an engineering goal, sometimes involving GIST, sometimes 
>NSLPs and sometimes both, the idea is to centralise this 
>discussion in one document, currently draft-loughney-nsis-ext 
>(which is reference [36]). Maybe the first paragraph of 
>section 9 should state this more strongly, and maybe [36] 
>should be normative.

I think so - Magnus, what we want to do is have GIST as a good
protocol spec, but address elsewhere the overall extensibility
issues, etc.  

>> B. There is no explanation for the large blocks of reserved codes
that 
>> exist.
>
>The rationale is that "If the current allocation policy turns 
>out to be wrong [e.g. because you suddenly start to run out in 
>a particular class] then the reserved space can be used for a 
>second attempt." I'm sure I had seen this in 2434, but it 
>certainly isn't there any more ;-)
>
>We could include that rationale more explicitly, or a 
>different rationale, or change the registry structure. 
>Opinions welcome.

I'm more comfortable reserving blocks as unused.  If GIST
turns out to be wildly successful, then we can revise this
at a later date.  We don't want to allow a gold-rush mentality,
allowing people to extend it in whatever way possible.

>> C. No rules for what is required to be included in an application for

>> assignment in any of these spaces.
>
>I'm not sure I really follow this. For example, for error 
>codes, it's stated that the error class and additional info 
>format must be defined; for object types, it's stated that the 
>AB flags must be defined (maybe one could add that the object 
>format is also needed); for MRMs there is a reference to 
>section 3.3 which describes what information is needed for a 
>new MRM. In some cases (such as new message type) I'm not sure 
>what to say beyond 'specification' since the range of things 
>that could be needed is so large.
>
>One aspect of this relates to document structure/section 
>content assumptions. The advice we got was to make section 9 
>purely aimed at IANA and the mechanics needed to get the 
>registry structure and policies documented correctly, on the 
>assumption that IANA will read nothing else. It therefore 
>intentionally doesn't contain all the information/guidance 
>that is needed to extend the protocol; implicitly one is 
>relying on the expertise of the people called up in the policy 
>(ietf/iesg/expert/whoever) to be familiar enough with the 
>specification as a whole to demand the right sort of 
>additional detail if it isn't already provided.
>
>It may be that this is the Wrong Way to do things. More 
>guidance needed ...

Yes.  The extensibility draft (update coming) should have the
application designer's rational for extending things.

>> D. The NSLP ID policy. Is it really envisioned that GIST will only be

>> used for NSLPs for which it is suitable that the IESG make decision
on 
>> them? Wouldn't a better policy be expert review or something which is

>> having a bit of lower bar. Having all proprietary users of GIST run
to 
>> the IESG for approval seems strange.
>
>This is probably an oversight, and we could certainly put in 
>some expert review/specification required space as well as the 
>experimental values. (But see under [A] above for discussion 
>of where guidance is written down, which applies most strongly 
>for this particular registry.)

Well, our former AD wanted to more tightly control this, but I think
something along the lines of Expert Review / Spec Required would be
OK to most of us here.

John

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis