Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-hierarchy-extensions-10

[Adrian Farrel]

Hi,

Thanks, Dan, for your response here.

Just to follow up on one point:

>> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
>> sends an open with P flag =0 can the response open be sent with a
>> P flag =1 and if yes what should be the action of the originator. I 
>> did not see any text about this case.
>
> DK>> According to RFC 5440, the Open message is not a request response
> exchange. Both entities send an Open message, and indeed they may even
> overlap. In our H-PCE extensions the P flag indicates that the sender
wants
> the receiver to act as its parent. In the example we give, it should be
fine
> for one party to not set the P flag in the first Open message seen on the
> wire, and for the second part to set the P flag in the second Open message
> seen on the wire. Therefore, I don't think this needs to be address as an
> implementor should be familiar with the Open message behavior. 

Dan is right that the Open is not a request response exchange, but two Open
messages that flow (one in each direction). The second might be sent in
response to the first, or they might be originated independently and be
matched up.

The P flag applies to the sender's requested relationship with the receiver.
It is possible for:
- neither Open to have the P flag set
- both Opens to have the P flag set
- either one of the Opens to have the P flag set
But, if both Opens have the P flag set then the session set-up must fail
according to 3.1.1.
If one speaker doesn't like the setting of the P flag it receives (most
notably if the receiver does not want to act as a parent) it fails the
session according to 4.1.

Thanks,
Adrian

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

Re: [Gen-art] Genart last call review of draft-ietf-mptcp-rfc6824bis-13

[Alissa Cooper]

Ines, thanks for your review. I see that your suggestions have been 
incorporated into the -15, so thanks to the authors for that. I have entered a 
DISCUSS ballot to chat about the interaction between the B-flag and version 
negotiation.

Alissa


> On Apr 26, 2019, at 5:51 AM, Ines Robles via Datatracker  
> wrote:
> 
> Reviewer: Ines Robles
> 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-mptcp-rfc6824bis-13
> Reviewer: Ines Robles
> Review Date: 2019-04-26
> IETF LC End Date: 2019-04-26
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> I believe the draft is technically good. This document is well written and
> clear to understand. I found the document quite complete.
> 
> The document specifies v1 of Multipath TCP, obsoleting v0 as specified in
> RFC6824, through clarifications and modifications primarily driven by
> deployment experience.
> 
> I have some minor questions for the authors.
> 
> Major issues: Not found
> 
> Minor issues: Not found
> 
> Nits/editorial comments:
> 
>Section 1.1 " the working group imposed..." --> " mptcp working group
>imposed..."
> 
> Some Comments/Questions:
> 
>  - Section 1.4: "...A1<->B2 and A2<->B2.  Although this additional session is
>  shown as being initiated from A2, it could equally have been initiated from
>  B1." --> would it be "initiated from B2"? or you mean B1 following the
>  example showed in Figure 2?
> 
>  - For Figure 5 (Pag.24), Figure 6(Pag.26) and Figure 11(Pag.40): would it be
>  correct to add "(rsv)" in the empty field (between "Subtype" and "B" fields)
>  as showed in Figure 12 (Pag. 44).?
> 
>  - Section 8.1:
>  "This document defines one additional subtype (ADD_ADDR) and updates the
>  references to this document for all subtypes except ADD_ADDR, which is
>  deprecated.":
> 
>  - It seems that the additional subtype is MP_TCPRST and not ADD_ADDR,
>  comparing table 2 between this draft and RFC6824.
> 
>  - Would it be correct state instead of "ADD_ADDR deprecated" to "ADD_ADDR
>  modified"? In Appendix E states; "The ADD_ADDR option (Section 3.4.1), which
>  is used to inform the other host about another potential address, is
>  different in several ways.  It now includes an HMAC of the added address, for
>  enhanced security.  In addition, reliability for the ADD_ADDR option has been
>  added: the IPVer field is replaced with a flag field, and one flag is
>  assigned (E) which is used as an 'Echo' so a host can indicate that it has
>  received the option."
> 
>  Thanks for this document,
> 
>  Ines.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-hierarchy-extensions-10

[daniel]

Hi Roni and Alissa, 

Thanks both for the review. We have addressed the comments from you both in
the latest version (11) but have not posted as it was so close to the IESG
telechat. A few comments  (DK>>) below on the specific comments:

Re: Minor issues:
> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on
the
> internet?

DK>> The draft (section 1.1) now includes the following text. 

>>
  The hierarchical relationship model is described in [RFC6805].
  It is applicable to environments with small groups of domains 
  where visibility from the ingress LSRs is limited.  As highlighted
  in [RFC7399] applying the hierarchical PCE model to very large 
  groups of domains, such as the Internet, is not considered 
  feasible or desirable.
<<

> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
sends an
> open with P flag =0 can the response open be sent with a P flag =1 and if
yes
> what should be the action of the originator. I did not see any text about
this
> case.

DK>> According to RFC 5440, the Open message is not a request response
exchange. Both entities send an Open message, and indeed they may even
overlap. In our H-PCE extensions the P flag indicates that the sender wants
the receiver to act as its parent. In the example we give, it should be fine
for one party to not set the P flag in the first Open message seen on the
wire, and for the second part to set the P flag in the second Open message
seen on the wire. Therefore, I don't think this needs to be address as an
implementor should be familiar with the Open message behavior. 

> Nits/editorial comments:
> 1. in section 1 "achild" should be " a child"

DK>> Fixed, thanks!

> 2.  Section 2.4 repeat some of the text from RFC6805 1.3.2.2 but using
> different sentence structure. Is there a reason to change the wording.

DK>> In the new version of our I-D (v11) we have three paragraphs for this
section, the first includes text from RFC6805 and uses quotes the reference
text, but we also include some additional discussion (in two further
paragraphs) text not used in 6805 to further define domain diversity. 

DK>> Again, thank you for the reviews. Its very much appreciated. We have a
new version ready which also addresses the above, and comments from Kyle
(secdir) and Mike (rtgdir). 

BR, Dan and the other authors. 

-Original Message-
From: Pce  On Behalf Of Alissa Cooper
Sent: 13 May 2019 18:23
To: Roni Even 
Cc: gen-art@ietf.org; draft-ietf-pce-hierarchy-extensions@ietf.org;
p...@ietf.org; i...@ietf.org
Subject: Re: [Pce] [Gen-art] Genart last call review of
draft-ietf-pce-hierarchy-extensions-10

Roni, thanks for your review. I raised your point about the missing OPEN
(error) case in my DISCUSS ballot. One comment below.

> On Apr 14, 2019, at 6:42 AM, Roni Even via Datatracker 
wrote:
> 
> Reviewer: Roni Even
> Review result: Almost 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-pce-hierarchy-extensions-??
> Reviewer: Roni Even
> Review Date: 2019-04-14
> IETF LC End Date: 2019-04-15
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> The document is almost ready for publication as a standard track RFC.
> 
> Major issues:
> 
> Minor issues:
> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on
the
> internet?

This text is the same as what appears in RFC 7399 and I think it captures
the intent clearly enough (although happy to see the authors answer your
question).

Thanks,
Alissa

> 
> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
sends an
> open with P flag =0 can the response open be sent with a P flag =1 and if
yes
> what should be the action of the originator. I did not see any text about
this
> case.
> 
> Nits/editorial comments:
> 1. in section 1 "achild" should be " a child"
> 2.  Section 2.4 repeat some of the text from RFC6805 1.3.2.2 but using
> different sentence structure. Is there a reason to change the wording.
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Pce mailing list
p...@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

Re: [Gen-art] Genart last call review of draft-ietf-pce-hierarchy-extensions-10

[Alissa Cooper]

Roni, thanks for your review. I raised your point about the missing OPEN 
(error) case in my DISCUSS ballot. One comment below.

> On Apr 14, 2019, at 6:42 AM, Roni Even via Datatracker  
> wrote:
> 
> Reviewer: Roni Even
> Review result: Almost 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-pce-hierarchy-extensions-??
> Reviewer: Roni Even
> Review Date: 2019-04-14
> IETF LC End Date: 2019-04-15
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> The document is almost ready for publication as a standard track RFC.
> 
> Major issues:
> 
> Minor issues:
> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on the
> internet?

This text is the same as what appears in RFC 7399 and I think it captures the 
intent clearly enough (although happy to see the authors answer your question).

Thanks,
Alissa

> 
> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE sends an
> open with P flag =0 can the response open be sent with a P flag =1 and if yes
> what should be the action of the originator. I did not see any text about this
> case.
> 
> Nits/editorial comments:
> 1. in section 1 "achild" should be " a child"
> 2.  Section 2.4 repeat some of the text from RFC6805 1.3.2.2 but using
> different sentence structure. Is there a reason to change the wording.
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[Gen-art] review of draft-ietf-roll-efficient-npdao-10.txt

[Francis Dupont]

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: Ready
Reviewer: Francis Dupont
Review Date: 2019/05/11
IETF LC End Date: 2019/05/21
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments: 
 - ToC page 2: bad padding in 2. and 2.1. titles in text format.

 - ToC page 2 and many other places: there is a problem with the
  "acknowledgement" word spelling: correct spelling is "acknowledgment"
  but the term is used both in the protocol including in the ToC and
  in the document for its acknowledgments usual section.

  I propose if the other protocol documents use the UK "acknowledgement"
  spelling to keep it for similar usages. In all cases the section title
  should be in US spelling so Acknowledgments.

 - 4.1 page 7, 4.4 5. page 12 and A.1 5. page 18: i.e. -> i.e.,

 - 4.3.1 page 10: atleast -> at least

 - 4.3.3 page 10: seqeunce -> sequence

 - 4.5.2 page 12: signalling -> signaling

 - 5 page 14 title: Acknowledgements -> Acknowledgments

 - from 6 page 14 to 6.3 page 16: Acknowledgement -> Acknowledgment

 - 6.1, 6.2 and 6.3 pages 15 and 16: there is a problem with the textual
  rendering of qualities: I got "oBit number..." without a space between
  the "o" and the entry name "Bit number".

 - authors page 21: please consider China -> PR China or simply move
  from country names to ISO IS 3166 2 letter codes (for instance
  France -> FR)?

Regards

francis.dup...@fdupont.fr

PS: as they are mostly aesthetic points there is no need to address them
by a new draft and BTW the RFC Editor can handle them.

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

[Gen-art] Genart telechat review of draft-ietf-opsawg-tacacs-13

[Stewart Bryant via Datatracker]

Reviewer: Stewart Bryant
Review result: Almost 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-opsawg-tacacs-13
Reviewer: Stewart Bryant
Review Date: 2019-05-13
IETF LC End Date: None
IESG Telechat date: 2019-05-16

Summary:

There are a number of issues called out below that need addressing before 
publication.

Someone needs to micro-check the text to make sure that all terms are defined 
and referenced.
I picked up a few, but there were a lot I did not have time to check.

Major issues:

SB> The IANA section should ask IANA to point to this RFC as a reference
SB> for port 49




   The first MD5 hash is generated by concatenating the session_id, the
   secret key, the version number and the sequence number and then
   running MD5 over that stream.  All of those input values are
   available in the packet header, except for the secret key which is a
   shared secret between the TACACS+ client and server.

SB> MD5 make a good checksum, but I am surprised to see it used in this
SB> application in a new protocol.

=

   All TACACS+ packets begin with the following 12-byte header.  The
   header describes the remainder of the packet:

SB> If ever there was an error in a long term session, how
SB> how would you find in in the following packet structure?
SB> Presumably from an incorrect major version and sequence number?

SB> Some details on the error cases and the unconditional "safety"
SB> of the protocol would be useful.

==

  TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01

  TAC_PLUS_AUTHEN_TYPE_PAP := 0x02

  TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03

  TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated)

  TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05

  TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06



SB> There are lots of lists similar to the above.
SB> I have not checked them all, but a number of the types 
SB> in this and subsequent parts of the design don't seem
SB> to be defined or have a definitive reference

===

 The START packet MUST contain a username and the data
   field MUST contain the PAP ASCII password.  A PAP authentication only
   consists of a username and password RFC 1334 [RFC1334] . The REPLY
   from the server MUST be either a PASS, FAIL or ERROR.

SB> Should there note be a note that RFC1334 is obsolete?

===

Minor issues:

The use of the term "packet" as a unit of data is confusing, since the protocol
is carried over TCP which is a streaming protocol.

They are really TACAS+ PDUs

=

(For example, Cisco uses "tty10"
   to denote the tenth tty line and "Async10" to denote the tenth async
   interface).  
SB> Is it correct to quote a particular vendor in an RFC of this type?



  TAC_PLUS_PRIV_LVL_MAX := 0x0f

  TAC_PLUS_PRIV_LVL_ROOT := 0x0f

  TAC_PLUS_PRIV_LVL_USER := 0x01

  TAC_PLUS_PRIV_LVL_MIN := 0x00

SB> Where are these defined?


Nits/editorial comments:

  The normative description of Legacy features such as ARAP and
SB> ARAP not expanded anywhere in document.

=

SB> telnet and rlogin need references

=
   is the user is connected via ISDN or a POTS, 
SB> Are ISDN and POTS well known IETF terms?

=

   It is not legal for an attribute name to contain either of the
   separators.  It is legal for attribute values to contain the
   separators.  
SB> Is "legal" the correct term here?


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