Re: [sidr] rpki-rtr-25 notes

[Stewart Bryant <[e-mail]>]

Randy

The process:

If they are just nits, then just tell the editor either
now or in Auth48.

If they are technical errors such as those that would be
excepted under errata - i.e. the intent of the IETF was
clear but the wrong words were put in the draft -
I will sign them off in Auth48.

If they are real technical changes, then it is too late,
a draft updating this RFC needs to be written.

... unless of course the protocol is broken and thus
we cannot proceed with publication, in which
case the draft has to be withdrawn from the RFC
Editor's queue and I need to figure out how far
back in the process I need to take the draft.

Fortunately I do not think that there are any
in the final category.

- Stewart

On 04/02/2012 23:43, Randy Bush wrote:
>> A) It's too early for nit edits
> not really.  as the iesg has approved this one, changes are going to be
> a process pain.  so this message pushes back on some of your suggestions
> which i would otherwise have gladly taken.
>
> perhaps the sponsoring AD will give me/us some guidance in this.
>
> also please excuse the roughness of my response.  i just hit san diego
> from a few time zones to the west.
>
>>     5.1, 3rd paragraph(/sentence): is only ->  is *the* only
> done
>
>> B) 5.9: the 2nd and 4th paragraphs seem to contradict each other.  I
>>     suspect that the intent is that you can send a generic error after a
>>     particular PDU, but the way it's phrased is a bit odd and it jumped
>>     out at me too.  How about:
>>
>>     If the error is generic (e.g. "Internal Error") and not associated
>>     with the PDU it is responding to, the Erroneous PDU field ...
> sure
>
>> C) 5.10 seems to indicate rcynic
> not in -26
>
>> D.1) "Unfortunately there is no protocol to do so on all currently used
>>       platforms".
>>       I actually doubt the validity of that statement.  I suspect SSH is
>>       likely available on them all.
> no it is not.  see voluminous discussion on list.  to save you the
> search, very common router platforms provide hard coded ssh client and
> server, but no ssh library which a protocol such as this can use.
>
>>       Or at least "nearly all" (and I doubt anything will ever reach
>>       "all").  I'd bet TLS is nearly ubiquitous as well, though
>>       probably less than SSH.
> about the same mess
>
>> D.2) The ordering of the 5th-8th(ish) paragraphs seems weird.  I'd group
>>       them together by subject such that the sections that talked about
>>       unprotected TCP should be next to each other and the ones that
>>       talked about the protected ones be together.  Thus, I think just
>>       moving the 2 unprotected paragraphs ("Caches and routers MUST..."
>>       and "If unprotected TCP...") to positions 5 and 6 would solve most
>>       of the oddities.
> not sure this is sufficiently problematic to tempt the $dieties post
> iesg approval.
>
>> D.3) I'm not sure that the whole concept of "MUST implement unprotected"
>>       is going to fly through a security review.
> it did.  after a bit of discussion.
>
>> D.4) There is some confusion regarding whether routers "use" vs "can be
>>       configured to use".  EG: "Caches and routers SHOULD use TCP-AO..."
>>       IMHO, this indicates they have a choice.  "SHOULD be able to use"
>>       might be a better wording choice implying its subject to
>>       configuration by the operator.  If you want a more complete list of
>>       places where I think this might be a problem, I can supply one of
>>       course.
> not sure this is sufficiently problematic to tempt the $dieties post
> iesg approval.
>
>> D.5) "If available to the operator...".  How would the router know
>>       what's available to the operator?  Or does this mean that if the
>>       device already implements protocol X, it must offer it as a
>>       configuration choice for rpki-rtr transport?  If so, that's not
>>       entirely clear.
> i think the meaning is pretty clear, though i guess it could be better
> phrased.  but it has to be available on *both* router and cache server.
>
>> D.6) I'd order the sub-sections to be in the same order as the list
>>       above it.  IE, TCP-AO is first in the list, so the TCP-AO
>>       sub-section should probably come first.
> probably.  but it may be safest to let the rfced hack it.
>
>> E) 7.1 SSH transport "Client routers SHOULD verify the public key of the
>>     cache".  Similar to D.4, I'd change this to "Client routers MUST
>>     be able to verify the public key of the cache".
> the looser but riskier phrasing was not an accident.
>
>> F) 7.2 TLS transports: the CN field is really being deprecated and I'd
>>     suggest using the subject alt name instead (SAN).
> see -26 for a complete rewrite of the tls section
>
>> G) section 8, paragraph 2 implies that the cache needs a list of names
>>     for the peer and I'm not sure this is true.  In fact much of that
>>     paragraph talks about the router/client side only, so I'd split the
>>     paragraph in two: one for cache requirements and one for the router
>>     requirements.
>>
>> H) section 8: I'd change "Key" to either "TheirKey" or "ItsKey"
> if so, probably should be CacheKey.  but whose key it is seems very
> clear from the next few words, yes?
>
>> I) section 8: "it would be prudent for the client"...  This seems like a
>>     good place for the word SHOULD to sneak in there somewhere.
> eenie meenie.  did not see a need to be that strongly prescriptive.
>
>> J) section 8: "if data from multiple caches are held, implementations
>>     MUST NOT distinguish between data sources when performing
>>     validation".
>>
>>     This one confuses me.  It's unclear, after reading the entire
>>     document, why you have a preference ordered list if the data from
>>     them all must be treated equally.
> proximity and security
>
> randy
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html