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

[Magnus Westerlund <[e-mail]>]

[e-mail] wrote:
> 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.  

Okay. I think that is totally okay as long as it is clear where this 
information is available. The proposed fix looks good.

> 
>>> 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.

Okay. I understand the motivation.

> 
>>> 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.

I am used to trying to write out clear enough rules about what the 
potential extender needs to fulfill so that this is easy. There is also 
the guidance to the reviewer of a proposed extension. It is clear that 
the guidance can never be all encompassing and the reviewer will have to 
make some decision on this.

Maybe putting the formal rules in the GIST spec and the guidance in the 
extensibility document is a good split.

> 
>>> 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.
> 
Okay. But as it has been established a WG consensus on the previous 
position my proposal would not be to change anything now. If the policy 
is really screwed up I guess we will need to publish an update on that.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

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