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

["Hancock, Robert" <[e-mail]>]

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

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

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


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

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

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

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

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