Subject: Re: [dtn] BPbis and BPSec

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 1 Feb 2017 22:28:36 +0000

Rick,

  I think BPSec would benefit from a final editing pass for consistency and some nits. I am unaware of any significant issues with the document. 

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Rick Taylor
> Sent: Tuesday, January 31, 2017 8:12 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [dtn] BPbis and BPSec
> 
> Hi Stephen,
> 
> Commenting as an individual...
> 
> 
> On Tue, 2017-01-31 at 10:06 +0000, Stephen Farrell wrote:
> > Hi Rick,
> >
> > On 30/01/17 10:27, Rick Taylor wrote:
> > >
> > > All,
> > >
> > > One of the most important issues that Stephen raises in his comments
> > > on BPbis is the relationship between the draft and BPsec.  As you
> > > are all aware, BPsec is not yet in WG Last Call.
> > >
> > > If I understand Kapali's comments correctly, he suggests two
> > > possible ways forward: The IPv4 way, and the IPv6 way.  I won't
> > > repeat his excellent description here, but the gist of is: IPv4 says
> > > "You can do extensions like this, and security might be a sensible
> > > extension",
> > > IPv6
> > > says "This is where the security extension fits".
> > >
> > > My understanding of the opinion of the working group is that BPsec
> > > is the adopted method for securing BPbis. So my question(s) to the
> > > WG group are:
> > >
> > > 1) Do we want to reference BPsec in BPbis (and vice-versa) - the
> > > IPv6
> > > method?
> > >
> > > 1a) If yes to 1) BPsec needs to go for Last Call, and this will hold
> > > back BPbis until both are ready: Is the WG happy to delay BPbis and
> > > TCPCLv4?
> > >
> > > 1b) If no to 1) Is the WG happy to have alternate valid methods of
> > > securing BPbis permitted by BPbis - The IPv4 method?
> > >
> > > Comments please, especially if you think I've missed the point!
> > I think this misses the point that we had a definition for how to
> > secure the experimental RFC 5050. I really don't see how it's credible
> > to promote 5050bis as a proposed standard but yet go "backwards" in
> > terms of not having a well-defined set of security mechanisms
> > documented for 5050bis.
> 
> I agree, BPbis without BPsec is a bad idea my opinion.
> 
> >
> > That says nothing about whether bpsec is mandatory to implement or use
> > nor about whether there could be additional specs that define how to
> > do security stuff.
> 
> And I agree that is currently unclear in the draft.
> 
> >
> > I also don't think the analogy with IPv6 and IPsec is that useful.
> 
> In my defence it wasn't my analogy, but it seemed a reasonable place to start
> a discussion.  I'm sorry if it's misleading.
> 
> >
> > In terms of your questions above, I guess it may be clear that I do
> > favour holding 5050bis in the WG or RFC editor queue until bpsec is
> > done. Doing that by making the reference to bpsec normative should
> > work fine if that's the outcome. And that also seems much more in line
> > with the WG charter which also calls for a standards track version of
> > RFC6257 to be produced.
> 
> Yes, a BPsec standards track document is a WG charter item.  My question for
> the group was trying to ask whether we should hold BPbis (and TCPCLv4) for
> it or not.  My personal opinion is to hold BPsec after WG Last Call, when the
> WG feels the draft is complete apart from BPsec.
> 
> Are there any more opinions out there? Ed, how 'ready' do you feel BPsec is?
> 
> Rick
> 
> >
> > S.
> >
> >
> > >
> > >
> > > Rick
> > > _______________________________________________
> > > dtn mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dtn
> > >
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Feb 2017 22:30:32 +0000

On 01/02/17 22:28, Birrane, Edward J. wrote:
> Rick,
> 
> I think BPSec would benefit from a final editing pass for consistency
> and some nits. I am unaware of any significant issues with the
> document.

If it helps, I'll commit to doing such a review.

If it helps even more: I'll commit to not doing such a
review:-)

S.

> 
> -Ed
> 
> --- Edward J. Birrane, III, Ph.D. Embedded Applications Group
> Supervisor Space Exploration Sector Johns Hopkins Applied Physics
> Laboratory (W) 443-778-7423 / (F) 443-228-3839
> 
> 
> 
>> -----Original Message----- From: dtn [mailto:[email-masked]]
>> On Behalf Of Rick Taylor Sent: Tuesday, January 31, 2017 8:12 AM 
>> To: [email-masked]; [email-masked] Subject: Re: [dtn]
>> BPbis and BPSec
>> 
>> Hi Stephen,
>> 
>>>> One of the most important issues that Stephen raises in his
>>>> comments on BPbis is the relationship between the draft and
>>>> BPsec.  As you are all aware, BPsec is not yet in WG Last
>>>> Call.
>>>> 
>>>> possible ways forward: The IPv4 way, and the IPv6 way.  I
>>>> won't repeat his excellent description here, but the gist of
>>>> is: IPv4 says "You can do extensions like this, and security
>>>> might be a sensible extension", IPv6 says "This is where the
>>>> security extension fits".
>>>> 
>>>> My understanding of the opinion of the working group is that
>>>> BPsec is the adopted method for securing BPbis. So my
>>>> question(s) to the WG group are:
>>>> 
>>>> 1) Do we want to reference BPsec in BPbis (and vice-versa) -
>>>> the IPv6 method?
>>>> 
>>>> 1a) If yes to 1) BPsec needs to go for Last Call, and this will
>>>> hold back BPbis until both are ready: Is the WG happy to delay
>>>> BPbis and TCPCLv4?
>>>> 
>>>> 1b) If no to 1) Is the WG happy to have alternate valid methods
>>>> of securing BPbis permitted by BPbis - The IPv4 method?
>>>> 
>>> I think this misses the point that we had a definition for how
>>> to secure the experimental RFC 5050. I really don't see how it's
>>> credible to promote 5050bis as a proposed standard but yet go
>>> "backwards" in terms of not having a well-defined set of security
>>> mechanisms documented for 5050bis.
>> 
>>> That says nothing about whether bpsec is mandatory to implement
>>> or use nor about whether there could be additional specs that
>>> define how to do security stuff.
>> 
>> In my defence it wasn't my analogy, but it seemed a reasonable
>> place to start a discussion.  I'm sorry if it's misleading.
>> 
>>> 
>>> In terms of your questions above, I guess it may be clear that I
>>> do favour holding 5050bis in the WG or RFC editor queue until
>>> bpsec is done. Doing that by making the reference to bpsec
>>> normative should work fine if that's the outcome. And that also
>>> seems much more in line with the WG charter which also calls for
>>> a standards track version of RFC6257 to be produced.
>> 
>> Yes, a BPsec standards track document is a WG charter item.  My
>> question for the group was trying to ask whether we should hold
>> BPbis (and TCPCLv4) for it or not.  My personal opinion is to hold
>> BPsec after WG Last Call, when the WG feels the draft is complete
>> apart from BPsec.
>> 
>>>> Rick _______________________________________________ dtn
>>>> mailing list [email-masked] 
>> _______________________________________________ dtn mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 1 Feb 2017 22:45:50 +0000

Any good technical review is welcome!

The major thing that needs to be updated is to adopt CBOR since BPbis had 
settled on CBOR since the last major update. Also some updates to the IANA 
Considerations and Conformance sections.

Since I'll be making a pass through the document shortly, if you can give this 
a first-order read in the next week, I'll be happy to try and merge any 
comments into the next pass of the document.

-Ed

---

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, February 01, 2017 5:31 PM
> To: Birrane, Edward J.; Rick Taylor; [email-masked]