Re: [Gen-art] Review of draft-ietf-mpls-tp-linear-protection-mib-11

[Benoit Claise]

Loa, Brian,

Brian, et.al.,

We could of course update 3812 (and 3813), though this would probably 
lead to another discussion on what updates means.


What is refereed to is that there is now another preferred method for
configuration - netconf/yang. In fact this draft doe not change 3812 or
propose a change, so there can not be an update. The document is just
noting that there is a change in the environment, and that for the time
being it will use RFC 3812 as specified.

Maybe Benoit have a take on this?
No strong views on updating RFC 3812, but the text in the intro section 
and the read-only conformance statement (WriteUp mentions: The MIB 
module has a read-only conformance statement so that vendors and/or 
network operators can choose to implement/operate the MIB module as 
read-only.) do the job IMO.


Regards, Benoit


/Loa

On 2017-01-16 06:04, Brian Carpenter wrote:

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of
draft-ietf-mpls-tp-linear-protection-mib-11

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-mpls-tp-linear-protection-mib-11.txt
Reviewer: Brian Carpenter
Review Date: 2017-01-16
IETF LC End Date: 2017-01-26
IESG Telechat date:

Summary: Ready with minor issues


Comment:


I have not reviewed most details of the MIB module itself. As usual,
I trust the MIB Doctors.

"We know of a handful of implementations (or intent to implement)."
Good. It would have been nice to see an Implementation Status section
under RFC 6982.

Minor issues:
-

   At the time of writing, Simple Network Management Protocol (SNMP)
SET
   is no longer recommended as a way to configure MPLS networks as
was
   described in RFC 3812 [RFC3812].

RFC3812 is explicit that it should be used for configuration:

   This MIB module should be used in conjunction with the
   companion document [RFC3813] for MPLS based traffic engineering
   configuration and management.

RFC3812 has not been formally updated or obsoleted. Therefore, it
seems
to me that the present draft should formally update RFC3812 in this
respect.

Does the same issue apply to RFC3813, whose Abstract also states that
it is used to configure an LSR?





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-mpls-tp-linear-protection-mib-11

[Loa Andersson]

Brian, et.al.,

We could of course update 3812 (and 3813), though this would probably 
lead to another discussion on what updates means.


What is refereed to is that there is now another preferred method for
configuration - netconf/yang. In fact this draft doe not change 3812 or
propose a change, so there can not be an update. The document is just
noting that there is a change in the environment, and that for the time
being it will use RFC 3812 as specified.

Maybe Benoit have a take on this?

/Loa

On 2017-01-16 06:04, Brian Carpenter wrote:

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of
draft-ietf-mpls-tp-linear-protection-mib-11

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-mpls-tp-linear-protection-mib-11.txt
Reviewer: Brian Carpenter
Review Date: 2017-01-16
IETF LC End Date: 2017-01-26
IESG Telechat date:

Summary: Ready with minor issues


Comment:


I have not reviewed most details of the MIB module itself. As usual,
I trust the MIB Doctors.

"We know of a handful of implementations (or intent to implement)."
Good. It would have been nice to see an Implementation Status section
under RFC 6982.

Minor issues:
-

   At the time of writing, Simple Network Management Protocol (SNMP)
SET
   is no longer recommended as a way to configure MPLS networks as
was
   described in RFC 3812 [RFC3812].

RFC3812 is explicit that it should be used for configuration:

   This MIB module should be used in conjunction with the
   companion document [RFC3813] for MPLS based traffic engineering
   configuration and management.

RFC3812 has not been formally updated or obsoleted. Therefore, it
seems
to me that the present draft should formally update RFC3812 in this
respect.

Does the same issue apply to RFC3813, whose Abstract also states that
it is used to configure an LSR?



--


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-bfcpbis-bfcp-websocket-13

[Ram Mohan R (rmohanr)]

Hi Robert,

Thanks for your review. Please see inline 

>-Original Message-
>From: Robert Sparks 
>Date: Thursday, 5 January 2017 at 4:05 AM
>To: "gen-art@ietf.org" 
>Cc: "draft-ietf-bfcpbis-bfcp-websocket@ietf.org" 
>, "bfcp...@ietf.org" 
>, "i...@ietf.org" >
>Subject: Review of draft-ietf-bfcpbis-bfcp-websocket-13
>Resent-From: 
>Resent-To: , , 
>, , , 
>>, , 
>, , , 
>>, Charles Eckel 
>Resent-Date: Thursday, 5 January 2017 at 4:05 AM

  >  Reviewer: Robert Sparks
   > Review result: Ready with Issues

   > I am the assigned Gen-ART reviewer for this draft. The General Area
   > Review Team (Gen-ART) reviews all IETF documents being processed
   > by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.

> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-bfcpbis-bfcp-websocket13-
> Reviewer: Robert Sparks
> Review Date: 2017-01-04
> IETF LC End Date: 2017-01-11
> IESG Telechat date: 2017-01-19
>
> Summary: Basically ready but with issues that need to be addressed
> before publication as a Proposed Standard
>
> Issues: 
>
> The BFCP spec (at draft-ietf-bfcpbis-rfc4582bis) relies heavily on
> recommendations it makes about the use of TLS or DTLS, and even goes
> to
> the point of specifyig a particular set of cipher suites to use wih
> those protocols when using them with BFCP. The security
> considerations
> section of that document details some specific attacks and how the
> use
> of TLS/DTLS mitigates them (providing some justification for the
> cipher
> suites that the document specifies).
>
> This document provides a _COMPLETELY DIFFERENT_ security mechanism
> (essentially punting entirely to whatever a websocket library
> provides
   > with the expectation that that will also be rooted in TLS) when it
   > substitutes websockets as the layer under BFCP. The security
   > considerations section needs to make this much more obvious -
   > implementers and deployers need to be see this as a strong-primary
   > point to avoid anyone thinking all the thinking that went into
> securing
 >   BFCP as captured in draft-ietf-bfcpbis-rfc4582bis still applies.

 I will add the below line in security consideration section. Is this 
sufficient?

NEW:
“The security considerations described in draft-ietf-bfcpbis-rfc4582bis are 
applicable here as well.”

  >  There should be more discussion about what a BFCP implementation that
   > cares about the attacks discussed in section 14 of
   > draft-ietf-bfcpbis-rfc4582bis requires of its library. The current
   > document gets most of the way there, but there are things missing.
>Shouldn't there be some discussion of ensuring the websocket library
   > used supports and will use the cipher suites called out in the core
   > BFCP document? If not, this document needs to be very explicit that
> you
> are only going to get the confidentiality protection the library
> provides.

 Good point. I would prefer to add a text something to the effect of:

“The security considerations mentioned in section 14 of 
[draft-ietf-bfcpbis-rfc4582bis] are applicable here. In order to mitigate
the attacks mentioned in section 14 of [draft-ietf-bfcpbis-rfc4582bis], it is 
RECOMMENDED that the clients and server use secure WebSocket 
with an encryption algorithm according to Section 7 of 
[draft-ietf-bfcpbis-rfc4582bis]”

> The current consideration section calls out relying on "a
 >   typical webserver-client model" and talks about server
  >   authentication,
   > but not client authentication. Section 8 shows most of what you're
   > expecting the server to do to authenticate the client, but you need
   > more text about what you expect the client libraries to be doing to
   > let
   > the server do its job (and you should point back to that from the
   > security considerations section).

 section 8 second para has text on what client should do. Also 4th para 
has some text.  Is there anything else you would like to see in that?
 I will add a line in security considerations

EXISTING:
The security model here is a typical webserver-
   client model where the client validates the server certificate and
   then connects to the server

NEW:
The security model here is a typical webserver-
   client model where the client validates the server certificate and
   then connects to the server. 

[Gen-art] Review of draft-ietf-mpls-tp-linear-protection-mib-11

[Brian Carpenter]

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of
draft-ietf-mpls-tp-linear-protection-mib-11

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-mpls-tp-linear-protection-mib-11.txt
Reviewer: Brian Carpenter
Review Date: 2017-01-16
IETF LC End Date: 2017-01-26
IESG Telechat date:  

Summary: Ready with minor issues


Comment:


I have not reviewed most details of the MIB module itself. As usual,
I trust the MIB Doctors.

"We know of a handful of implementations (or intent to implement)."
Good. It would have been nice to see an Implementation Status section
under RFC 6982.

Minor issues:
-

   At the time of writing, Simple Network Management Protocol (SNMP)
SET
   is no longer recommended as a way to configure MPLS networks as
was
   described in RFC 3812 [RFC3812].

RFC3812 is explicit that it should be used for configuration:

   This MIB module should be used in conjunction with the
   companion document [RFC3813] for MPLS based traffic engineering
   configuration and management.

RFC3812 has not been formally updated or obsoleted. Therefore, it
seems
to me that the present draft should formally update RFC3812 in this
respect.

Does the same issue apply to RFC3813, whose Abstract also states that
it is used to configure an LSR?

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-elie-nntp-tls-recommendations-03

[Julien ÉLIE]

Hi Jouni,

Thanks for your latest review of -04!

FYI, as you mentioned it in -03, the Author's Note Section will be 
removed by the RFC Editor.  It is what they have just done for the 
following draft currently in AUTH48:

  https://datatracker.ietf.org/doc/draft-murchison-nntp-compress/

--
Julien ÉLIE

« – Dis, je crois avoir entendu parler gothique par là !
  – Tu as des visions, Pamplemus ! » (Astérix)


Le 04/01/2017 à 21:36, Julien ÉLIE a écrit :

Hi Jouni,


(I did review the -00 version and my comment have been already
addressed in -01)


Thanks for your verification :)



Nits/editorial comments:

For the consistency Section 1.2. Author's note should probably be also
tagged and explained how the RFC Editor is supposed to handle it. I
assume Section 1.2. will be removed from the final publication.


RFC Editor cannot handle it with their current tools.  Actual
publication of RFCs in the new formats allowing UTF-8 is about 18 months
away according to the timeline listed on the RSE slides
from IETF 97.  That's why Section 1.2 is still here and not scheduled to
be removed (like Section 1.3 of
).



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-elie-nntp-tls-recommendations-04

[Jouni Korhonen]

Reviewer: Jouni Korhonen
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-elie-nntp-tls-recommendations-??
Reviewer: Jouni Korhonen
Review Date: 2017-01-15
IETF LC End Date: 2016-12-26
IESG Telechat date: 2017-01-19

Summary: ready

Major issues: None.

Minor issues: None.

Nits/editorial comments: 

I have reviewed earlier versions of this document and the comments I
had then have been addresses. I have no issues from my side.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-ietf-sidr-rpki-oob-setup-06

[Roni Even]

Reviewer: Roni Even
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-sidr-rpki-oob-setup-06
Reviewer: Roni Even
Review Date: 2017-01-15
IETF LC End Date: 2017-01-10
IESG Telechat date: 2017-01-19

Summary: This draft is ready for publication as a standard track RFC.

Major issues:

Minor issues:

Nits/editorial comments: 


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art