Hi, That was quick!
> >> 2) Is the INTER-LAYER Object Flags registry really needed, given the > >> limited amount of flag space??? > > > > I think so, yes. > > The registry is to stop collisions. > > I don't see how the size of the range makes much (any) difference. > > If you don't have a registry, anyone can grab any bit and there is a > > requirement > that everyone reads every draft to avoid collisions. > > Given the flag field in this document is specified as reserved, any new doc > that > specifies a new flag must update this document. Hopefully the process works > well enough to not cause collisions (I’m confident of that). > > The size matters, as I would expect that the number of documents that update > this part is rather limited and therefore this is a viable and scalable > approach. > > However, if you’d decide to keep the registry, you should not specify the > remaining flag part as reserved (otherwise you still have to update this > document > even if you have a registry). > > I would still recommend not to use a registry. There is a difference between "Reserved" in an IANA registry and "reserved" in the text. I believe we have used a tried and tested wording (well, as long as I can recall) where: - unassigned bits are described in the protocol as "reserved - must be set to zero, should be ignored" - unassigned bits are flagged in the registry as "unassigned" Such a formula never requires an update to the base RFC. > >> 3) Security Consideration: "Inter-layer traffic engineering with PCE may > >> raise new security > >> issues when PCE-PCE communication is done between different layer > >> networks for inter-layer path computation." > >> This text is not very helpful as this section is meant to be used to > >> document these new issues. > > > > I'm trying to avoid saying "this should be obvious to one skilled in the > > art" since > that always annoys me when the US patent office says it to me. > > > > We could fill this out as... > > > > OLD > > Inter-layer traffic engineering with PCE may raise new security > > issues when PCE-PCE communication is done between different layer > > networks for inter-layer path computation. Security issues may also > > exist when a single PCE is granted full visibility of TE information > > that applies to multiple layers. > > > > Path-Key-based mechanism defined in [RFC5520] MAY be applied to > > address the topology confidentiality between different layers. > > NEW > > Inter-layer traffic engineering with PCE may raise new security > > issues when PCE-PCE communication is done between different layer > > networks for inter-layer path computation because information about > > the networks at different layers will necessarily be exposed in > > computation results. Furthermore, a PCE in one layer might use > > computation requests to "probe" for information about the network > > in the other layer. > > > > Security issues may also exist when a single PCE is granted full > > visibility of TE information that applies to multiple layers. > > > > In both cases cited here, the security concerns are to do with > > exposure of information about a network to parties outside that > > network. These concerns relate to the privacy of the commercial > > details of a network, but it should also be understood that > > distributing information about networks extends the attack surface > > for those networks. > > > > Path-Key-based mechanism defined in [RFC5520] MAY be applied to > > address the topology confidentiality between different layers. > > END > > Thanks! Much better! OK. Perhaps that can get added as an RFC Editor note? Cheers, Adrian _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
