Re: [Gen-art] Genart last call review of draft-wu-l3sm-rfc8049bis-07

[Jari Arkko <[e-mail]>]

Thanks for your response, Qin.

Some further comments:

> [Qin]: Yes, there are implementations, something broken in RFC8049 needs to get right.

Cool..

> I'm not sure I fully understand the need for "SP MUST honour <requirement>"
> language in the document. Are there parts of the described model that they SP is *not* required to honour? Other than the explicit strict true/false settings? And in any case, sizeable networks are likely to have issues that might require negotiation/human involvement.
> 
> [Qin]: Explicit settings are covered by sub-section of section 6.6, such as device constraint, Site Location constraint/parameter, access type.
> Unlike RFC8049, RFC8049bis change "SP SHOULD honor" into "SP MUST honor”. 

OK

> I don't understand how 6.9.1 can say there is no authentication support but then 6.9.2 (encryption) talks about authentication keys. I'd suggest some rethinking or at least clarification might be needed here.
> 
> [Qin]: Authentication provides you access to a resource like a computer or a network. Encryption provides confidentiality and controls whether an object can be read or not.
> Both Authentication and Encryption are site level parameters and applicable to site connection. Pre-share key as encryption parameter can be used, e.g., for routing protocol authentication.
> But pre-share key parameter is not authentication parameter, one example I have for authentication parameter is authentication algorithm which is not specified in the model,
> We will see how to clarify this in the model. thanks.

Please do. I’m not sure the auth/encr distinction is as useful as it may appear initially. You often have to authenticate in order to encrypt. Another possible distinction might be whether you use cryptographic protection for routing protocol or payload traffic protection.

(It could be that when you say “authentication” or “encryption” you mean very specific things that I’m not understanding. Being more specific usually helps. I’m not suggesting you do describe all possible security options that might exist, but being precise would be useful.)

> In the security considerations, I would note that if these models are used not merely for creation of networks, but also their modification, the consequences of inadvertent or malicious modifications can severe and network wide. Perhaps that could be discussed.
> 
> [Qin]:Security consideration section has already considered both creation of networks and but also their modification, see the text in security consideration section as follows:
> "
>   The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be
>   carefully created, read, updated, or deleted as appropriate.
> “

IMHO, that is not particularly detailed, nor does it tell me useful things that I can do in my implementation or deployment.

Jari