[NSIS] Re: AD comments on draft-ietf-nsis-ntlp-14

[Magnus Westerlund <[e-mail]>]

See inline

Hancock, Robert skrev:
> magnus,
> 
> thanks for the encouragement.
> 
> i'll send a separate response for your comments (1) and (2) 
> [which need some work].
> 
> for the rest, i have proposed solutions below - discussion welcome.
> 
> robert h.
> 
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:[e-mail]] 
>> Sent: 26 November 2007 16:10
>> To: [e-mail]; NSIS
>> Subject: AD comments on draft-ietf-nsis-ntlp-14
>>
>> Hi,
>>
>> I am sorry for the long time this AD review has taken. I 
>> really liked to read the document from first to last word 
>> before progressing it. I have now done this and thinks the 
>> document is in pretty good shape. I would appreciate an 
>> updated version as soon as we have resolved the questions.
> 
> [snip]
> 
>> 3. Section 5.3.3, page 59:
>>
>> "A suitable approach
>>    is to restrict the token bucket parameters so that the mean output
>>    rate is a small fraction, such as 5%, of the node's lowest-speed
>>    interface."
>>
>> I think it should be made clear that the token bucket 
>> parameter for bit-rate is "no larger than 5%" rather than 
>> suggesting that 5% is a general good value.
> 
> something like:
> A suitable approach is to restrict the token bucket parameters so that
> the mean output rate is a small fraction of the node's lowest-speed
> interface. It is RECOMMENDED that this rate is no more than 5%.
> 
> (I don't think this can really be MUST - a silly counterexample would be
> a terabit router which you can telnet into over GSM. but the RECOMMENDED
> should make it clear to the implementor that this is a serious piece of
> advice.)

Yes, that seems reasonable.

> 
>> 4. Section 5.7.3.1:
>>
>> "For
>>    example, *.example.com in the APD would match certificates for
>>    a.example.com, foo.example.com, *.example.com, etc., but would not
>>    match example.com.  Similarly, a certificate for 
>> *.example.com would
>>    be valid for APD identities of a.example.com, foo.example.com,
>>    *.example.com, etc., but not example.com."
>>
>> Is it intentional to have two sentences saying the same 
>> thing, or am I dense here. It looks very much like a repeat.
> 
> Not quite:
> *) The first sentence states that if you populate your authorised
> peer database with an entry like
> *.example.com	ALLOW
> then a node presenting a certificate with an identity like a.example.com
> will be authorised.
> *) The second sentence states this if you have an entry in your APD like
> a.example.com	ALLOW
> then a node presenting a certificate presenting the identity
> *.example.com will be authorised.
> 

Okay

>> 5. Section 9: NSLP ID
>>
>> I actually wonder about the selection of IESG approval for 
>> new NSLP IDs.
>>  Isn't that kind of restricting? Sure, it can potentially be 
>> easier to register than specification required. However, it 
>> does put load on the IESG. It also assumes that the IESG will 
>> have enough clue in the future to know what the correct way 
>> to handle a registration requests. Can someone provide me 
>> with the WGs reasoning behind this policy?
> 
> Here there may be some history (John channelling your predecessor
> ADs). I think the rationale is as follows:
> - IESG review includes standards action as a sort of sub-case
> - we didn't want a plethora of proprietary protocols
> - we anticipated that one source of proposals would be SDOs
>   (for which the evaluation needs to take into account the IETF's
>   interaction with that SDO in handling some bigger standardisation
>   question, and so is not simply a matter of expert review)
> 
> It's obviously easy to modify the assignment rules, and to be honest
> I have no really strong opinions against a more relaxed set of
> policies here.

Okay, as long as the WG knows what it is getting itself into. My main
concern was that being restricted will in fact hamper deployment. But it
appears that you like to avoid proprietary NSLPS. If that is the WG's
conclusion I am fine.


> 
> 
>> 6. Appendix A. I think the text about "reserved" and its 
>> meaning needs to be moved from section A.2 to the front text 
>> for Appendix A. Otherwise it is wrongly scoped and does not 
>> cover A.1 or any A.3...
> 
> OK
> 
>> 7. Section A.1: There is no explicit mention of what values 
>> should be listed in the version field for this spec. Earlier 
>> it says this is Version 1 of GIST, but that could be encoded 
>> both a 0 and 1 in this field based on previous protocols from IETF.
> 
> I would say '1'.  

Sure, but can we please get some word in there saying that.

> 
>> 8. ID-nits warnings:
>>
>>   == Unused Reference: '14' is defined on line 5231, but no explicit
>>      reference was found in the text
> 
> I would propose to add that as an additional reference (alongside the
> framework).
> 
>>   -- Obsolete informational reference (is this intentional?): 
>> RFC 2246 (ref.
>>      '15') (Obsoleted by RFC 4346)
> 
> aaaaaaaaaaaaargh - the TLS specification version game ...
> 
> The place where this is referred from (section 5.7.3) was worked
> over in conjuction with the security ADs; note that there is a
> normative reference to 4346 also. but since we allow falling back to 
> v1.0, we have this reference also. 
> 
> [this particular open sore seems to pop up for any protocol which
> can be layered on TLS - see the discussion on
> draft-ietf-atompub-protocol
> for example. in this particular case, i think the text and references
> are OK. personally I think it would be more rationale for the
> reference to 2246 to be normative, but then we would get into a much
> more complicated set of procedural questions.]
> 

Sure, I should have reacted to that being TLS. I know from the
discussion that it is fine to refer to earlier version.

>>   -- Obsolete informational reference (is this intentional?): 
>> RFC 2766 (ref.
>>      '18') (Obsoleted by RFC 4966)
> 
> will update
> 
>>   -- Obsolete informational reference (is this intentional?): 
>> RFC 2960 (ref.
>>      '19') (Obsoleted by RFC 4960)
> 
> will update
> 
>> I definitely like to know if the new versions are fine or not.
> 
> summary: yes for all of them, but the informational reference
> to TLS1.0 should remain (IMHO).

Sure

> 
>>
>>   == Outdated reference: A later version (-04) exists of
>>      draft-ietf-behave-turn-03
>>
>>   == Outdated reference: A later version (-15) exists of
>>      draft-ietf-nsis-nslp-natfw-14
>>
>>   == Outdated reference: A later version (-02) exists of
>>      draft-pashalidis-nsis-gist-legacynats-01
>>
>>   == Outdated reference: A later version (-05) exists of
>>      draft-pashalidis-nsis-gimps-nattraversal-04
>>
>>   == Outdated reference: A later version (-04) exists of
>>      draft-ietf-nsis-ntlp-statemachine-03
>>
>>   == Outdated reference: A later version (-08) exists of
>>      draft-ietf-tcpm-tcpsecure-07
> 
> will fix all of these. nice to see that we have ony fallen
> one version behind.
> 

No, problem. I know it is basically impossible to keep all draft
references upto date.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
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