Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
On Mon, Sep 17, 2018 at 10:58:59AM +0900, Hiroshi Tsunoda wrote: > Hi Benjamin, > > > I was thinking about each table having its own subsection. > > In particular, when I was reading, it was easy for me to miss the comments > > like "-- Table of PMSI information", especially when the comment was on a > > different page from the actual MIB contents. Having a section number might > > make those boundaries more clear. > > Thank you for your clarification. > I have carefully considered your suggestion, but it looks a bit redundant > for me when each table has its own subsection. > Consequently, I have decided to keep the original style. > I would appreciate your understanding of my decision. It is entirely your decision and I can see how my suggestion would not necessarily be the best choice. Thanks for letting me know, Benjamin ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
On Sat, Sep 15, 2018 at 11:38:30AM +0900, Hiroshi Tsunoda wrote: > Hi Benjamin, > > Thank you very much for your thorough review and comments. > My replies are inline. > > > Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security > > considerations in the list of address-related objects that may have > > privacy/security impact. That list is predicated on being "objects with a > > MAX-ACCESS other than not-accessible", but all the instances of > > mvpnAdvtPeerAddr I found in the body text were marked as not-accessible. > > Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs, > > mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and > > mvpnMrouteNextHopAddr. > > I have received the advice from the MIB doctor on this matter and > I am going to update the draft along with the advice. Excellent, I am sure the MIB doctor's advice is better than mine in this matter. > > (Incidentally, why ar mvpnMrouteCmcastSourceAddrs > > and mvpnMrouteNextHopSourceAddrs plural with the final 's'?) > > For example, the DESCRPIPTION of mvpnMrouteCmcastSourceAddrs > says as follows. > > "The network address which, along with the > corresponding mvpnMrouteCmcastSourcePrefixLength object, > identifies the sources for which this entry contains > multicast routing information." > > Thus, this object identifies the (multiple) multicast sources, not a > single source. > Consequently, I prefer that the names of these objects are in plural form. Ah, thank you for the explanation. > > Perhaps using subsections to separate the various tables' descriptions > > would aid readability. > > Please let me confirm one thing. > I assume that you are talking about "Sec 3.1. Summary of MIB Module." > Do you mean that the description of each table should be in each > different subsection? > Or, do you mean that there should be one subsection including a set of > tables' descriptions? I was thinking about each table having its own subsection. In particular, when I was reading, it was easy for me to miss the comments like "-- Table of PMSI information", especially when the comment was on a different page from the actual MIB contents. Having a section number might make those boundaries more clear. Thanks, Benjamin > Thanks in advance, > > -- tsuno > > 2018-09-12 10:49 GMT+09:00 Benjamin Kaduk : > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-bess-mvpn-mib-11: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ > > > > > > > > -- > > COMMENT: > > -- > > > > A general comment that we've been making on lots of documents in this > > space is that it would be nice to be in a place where the acronym "VPN" > > implies transport encryption. It's unclear that it's appropriate to request > > changes to this specific document toward that end, though. > > > > Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security > > considerations in the list of address-related objects that may have > > privacy/security impact. That list is predicated on being "objects with a > > MAX-ACCESS other than not-accessible", but all the instances of > > mvpnAdvtPeerAddr I found in the body text were marked as not-accessible. > > Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs, > > mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and > > mvpnMrouteNextHopAddr. (Incidentally, why ar mvpnMrouteCmcastSourceAddrs > > and mvpnMrouteNextHopSourceAddrs plural with the final 's'?) > > > > Perhaps using subsections to separate the various tables' descriptions > > would aid readability. > > > > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
Hi Benjamin,
Yes now I see your point and all I can do is to agree with it.
As you know the story with right terminology is evolved to be even more
"funny". The real true and encrypted VPNs in the Internet are called SD-WAN
these days without any indication that there is privacy assurance while VPN
term is merely separating default IP reachability between parties if we
look at say L3VPNs. Sure there are also point to point IPSec VPNs which do
either encrypt or assure not compromised payload delivery.
So I guess indeed terminology is pretty confusing - and in fact it is
confusing even to technical people who are just not that ultimately
familiar with RFC4364 protocol and vendor's implementation details. Also
let's note that RFC4364 is often used outside of Internet and perhaps there
in those enterprise private networks encryption is not that much of a
necessity.
> From my view as Security AD, it would be quite a shame if we ended up in
an
> Internet world where some corporate purchaser buys a product labelled
"VPN"
> thinking it will protect (encrypt) his company's data, when in fact it
only
> provides IP reachability separtaion.
Well I think the market is here to help us ...
Today I see use of L3VPNs from SPs as rather fading away. SD-WAN have clear
advantages from both technical and economical points of view that I am not
sure if struggle to either rename or add mandatory or even optional
encryption to RFC4364 is really worth the effort.
A bit side observation is that the example described above leads me to
believe that the main fundamental problem is that today IETF does not (at
least to the best of my knowledge) coordinate names for new protocols or
protocol extensions in any way. Anyone can invent his own name and once the
document passes WG validating its technical merits I have not heard of many
cases where IESG or IETF wide review would change the name itself of the
proposal. And maybe in some cases it should
Kind regards,
Robert.
On Sat, Sep 15, 2018 at 2:51 AM Benjamin Kaduk wrote:
> On Wed, Sep 12, 2018 at 10:29:49AM +0200, Robert Raszuk wrote:
> > Hi Benjamin,
> >
> > > A general comment that we've been making on lots of documents in this
> > > space is that it would be nice to be in a place where the acronym "VPN"
> > > implies transport encryption.
> >
> > Let me observe that for a lot of work in IETF term "VPN" does *not* imply
> > any form of either transport or payload encryption.
>
> I am aware that this is the current state, yes. That's why I used the
> phrasing I did, namely, "it would be nice to be in a place", with the
> implication that we currently aren't.
>
> > In fact here the MVPN which is derivative of L3VPNs do not imply use of
> any
> > encryption at all.
> >
> > The term "VPN" here is really all about IP reachability separation.
> >
> > So with this in mind can you please clarify your above comment ?
>
> Sure! In recent years, the IETF as a whole seems to have shifted toward
> placing a greater emphasis on the privacy protection of user data from "the
> network" (not the network operators, necessarily, but an attacker that has
> coopted or compromised core nodes). This is, in some sense, the core point
> of RFC 7258. With this renewed interest in "private" and "privacy"
> referring to obscuring user data from intermediates (i.e., encryption),
> using the same word "private" to refer to a different concept ("not
> shared", as the IP reachability separation embodies) can lead to confusion.
> This is particularly pronounced in the case of the acronym "VPN", when
> (encrypting) corporate VPNs are nigh-ubiquitous, and end users have
> (encrypting) VPNs to pierce firewalls that get in their way, avoid
> geographic-based content restrictions, and the like.
>
> While the network engineers and RFC authors know there are different
> contexts for the term in current usage, the popular media really does not,
> and there are many consumers of RFCs that are not intimately involved in
> their development. So as a matter for the "good of the Internet", my
> position is that reducing this potential for confusion is desirable.
> From my view as Security AD, it would be quite a shame if we ended up in an
> Internet world where some corporate purchaser buys a product labelled "VPN"
> thinking it will protect (encrypt) his company's data, when in fact it only
> provides IP reachability separtaion.
>
> I don't have an alternative term I want to push for the "not shared" case
> (though just "Virtual Network" and its parallels to network virtualization
> does come to mind); even a passing mention that this instance of VPN does
> not provide data confidentiality would be a big improvemnet, in my mind.
> But this is a very broad topic, and it needs to be eased into gradually, so
> I'm starting by just mentioning the potential issue when it comes up, with
> no expectation of changing the *current* document -- this is more of a
> long-term goal.
>
> -Benjamin
>
> >
> >
> > On Wed,
Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
Hi Benjamin, Thank you very much for your thorough review and comments. My replies are inline. > Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security > considerations in the list of address-related objects that may have > privacy/security impact. That list is predicated on being "objects with a > MAX-ACCESS other than not-accessible", but all the instances of > mvpnAdvtPeerAddr I found in the body text were marked as not-accessible. > Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs, > mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and > mvpnMrouteNextHopAddr. I have received the advice from the MIB doctor on this matter and I am going to update the draft along with the advice. > (Incidentally, why ar mvpnMrouteCmcastSourceAddrs > and mvpnMrouteNextHopSourceAddrs plural with the final 's'?) For example, the DESCRPIPTION of mvpnMrouteCmcastSourceAddrs says as follows. "The network address which, along with the corresponding mvpnMrouteCmcastSourcePrefixLength object, identifies the sources for which this entry contains multicast routing information." Thus, this object identifies the (multiple) multicast sources, not a single source. Consequently, I prefer that the names of these objects are in plural form. > Perhaps using subsections to separate the various tables' descriptions > would aid readability. Please let me confirm one thing. I assume that you are talking about "Sec 3.1. Summary of MIB Module." Do you mean that the description of each table should be in each different subsection? Or, do you mean that there should be one subsection including a set of tables' descriptions? Thanks in advance, -- tsuno 2018-09-12 10:49 GMT+09:00 Benjamin Kaduk : > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bess-mvpn-mib-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ > > > > -- > COMMENT: > -- > > A general comment that we've been making on lots of documents in this > space is that it would be nice to be in a place where the acronym "VPN" > implies transport encryption. It's unclear that it's appropriate to request > changes to this specific document toward that end, though. > > Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security > considerations in the list of address-related objects that may have > privacy/security impact. That list is predicated on being "objects with a > MAX-ACCESS other than not-accessible", but all the instances of > mvpnAdvtPeerAddr I found in the body text were marked as not-accessible. > Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs, > mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and > mvpnMrouteNextHopAddr. (Incidentally, why ar mvpnMrouteCmcastSourceAddrs > and mvpnMrouteNextHopSourceAddrs plural with the final 's'?) > > Perhaps using subsections to separate the various tables' descriptions > would aid readability. > > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
On Wed, Sep 12, 2018 at 10:29:49AM +0200, Robert Raszuk wrote:
> Hi Benjamin,
>
> > A general comment that we've been making on lots of documents in this
> > space is that it would be nice to be in a place where the acronym "VPN"
> > implies transport encryption.
>
> Let me observe that for a lot of work in IETF term "VPN" does *not* imply
> any form of either transport or payload encryption.
I am aware that this is the current state, yes. That's why I used the
phrasing I did, namely, "it would be nice to be in a place", with the
implication that we currently aren't.
> In fact here the MVPN which is derivative of L3VPNs do not imply use of any
> encryption at all.
>
> The term "VPN" here is really all about IP reachability separation.
>
> So with this in mind can you please clarify your above comment ?
Sure! In recent years, the IETF as a whole seems to have shifted toward
placing a greater emphasis on the privacy protection of user data from "the
network" (not the network operators, necessarily, but an attacker that has
coopted or compromised core nodes). This is, in some sense, the core point
of RFC 7258. With this renewed interest in "private" and "privacy"
referring to obscuring user data from intermediates (i.e., encryption),
using the same word "private" to refer to a different concept ("not
shared", as the IP reachability separation embodies) can lead to confusion.
This is particularly pronounced in the case of the acronym "VPN", when
(encrypting) corporate VPNs are nigh-ubiquitous, and end users have
(encrypting) VPNs to pierce firewalls that get in their way, avoid
geographic-based content restrictions, and the like.
While the network engineers and RFC authors know there are different
contexts for the term in current usage, the popular media really does not,
and there are many consumers of RFCs that are not intimately involved in
their development. So as a matter for the "good of the Internet", my
position is that reducing this potential for confusion is desirable.
>From my view as Security AD, it would be quite a shame if we ended up in an
Internet world where some corporate purchaser buys a product labelled "VPN"
thinking it will protect (encrypt) his company's data, when in fact it only
provides IP reachability separtaion.
I don't have an alternative term I want to push for the "not shared" case
(though just "Virtual Network" and its parallels to network virtualization
does come to mind); even a passing mention that this instance of VPN does
not provide data confidentiality would be a big improvemnet, in my mind.
But this is a very broad topic, and it needs to be eased into gradually, so
I'm starting by just mentioning the potential issue when it comes up, with
no expectation of changing the *current* document -- this is more of a
long-term goal.
-Benjamin
>
>
> On Wed, Sep 12, 2018 at 3:49 AM, Benjamin Kaduk wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-bess-mvpn-mib-11: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > A general comment that we've been making on lots of documents in this
> > space is that it would be nice to be in a place where the acronym "VPN"
> > implies transport encryption. It's unclear that it's appropriate to
> > request
> > changes to this specific document toward that end, though.
> >
> > Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security
> > considerations in the list of address-related objects that may have
> > privacy/security impact. That list is predicated on being "objects with a
> > MAX-ACCESS other than not-accessible", but all the instances of
> > mvpnAdvtPeerAddr I found in the body text were marked as not-accessible.
> > Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs,
> > mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and
> > mvpnMrouteNextHopAddr. (Incidentally, why ar mvpnMrouteCmcastSourceAddrs
> > and mvpnMrouteNextHopSourceAddrs plural with the final 's'?)
> >
> > Perhaps using subsections to separate the various tables' descriptions
> > would aid readability.
> >
> >
> > ___
> > BESS mailing list
> > BESS@ietf.org
> > https://www.ietf.org/mailman/listinfo/bess
> >
___
BESS mailing list
BESS@ietf.org
Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
Hi Benjamin, > A general comment that we've been making on lots of documents in this > space is that it would be nice to be in a place where the acronym "VPN" > implies transport encryption. Let me observe that for a lot of work in IETF term "VPN" does *not* imply any form of either transport or payload encryption. In fact here the MVPN which is derivative of L3VPNs do not imply use of any encryption at all. The term "VPN" here is really all about IP reachability separation. So with this in mind can you please clarify your above comment ? Kind regards, Robert. On Wed, Sep 12, 2018 at 3:49 AM, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bess-mvpn-mib-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ > > > > -- > COMMENT: > -- > > A general comment that we've been making on lots of documents in this > space is that it would be nice to be in a place where the acronym "VPN" > implies transport encryption. It's unclear that it's appropriate to > request > changes to this specific document toward that end, though. > > Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security > considerations in the list of address-related objects that may have > privacy/security impact. That list is predicated on being "objects with a > MAX-ACCESS other than not-accessible", but all the instances of > mvpnAdvtPeerAddr I found in the body text were marked as not-accessible. > Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs, > mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and > mvpnMrouteNextHopAddr. (Incidentally, why ar mvpnMrouteCmcastSourceAddrs > and mvpnMrouteNextHopSourceAddrs plural with the final 's'?) > > Perhaps using subsections to separate the various tables' descriptions > would aid readability. > > > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-mvpn-mib-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ -- COMMENT: -- A general comment that we've been making on lots of documents in this space is that it would be nice to be in a place where the acronym "VPN" implies transport encryption. It's unclear that it's appropriate to request changes to this specific document toward that end, though. Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security considerations in the list of address-related objects that may have privacy/security impact. That list is predicated on being "objects with a MAX-ACCESS other than not-accessible", but all the instances of mvpnAdvtPeerAddr I found in the body text were marked as not-accessible. Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs, mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and mvpnMrouteNextHopAddr. (Incidentally, why ar mvpnMrouteCmcastSourceAddrs and mvpnMrouteNextHopSourceAddrs plural with the final 's'?) Perhaps using subsections to separate the various tables' descriptions would aid readability. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
