Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[mohamed.boucadair]

Hi Dino, 

OLD: 

   Values in the "Not Assigned" range can be assigned according to
   procedures in [RFC8126].

NEW:

   Values in the "Not Assigned" range can be assigned via Standards
   Action [RFC8113].

Cheers,
Med

> -Message d'origine-
> De : Dino Farinacci [mailto:farina...@gmail.com]
> Envoyé : mercredi 19 décembre 2018 19:00
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; l...@ietf.org;
> draft-ietf-lisp-rfc8113bis@ietf.org
> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
> 
> What does fixing in (1) mean?
> 
> Dino
> 
> > On Dec 19, 2018, at 3:51 AM, 
>  wrote:
> >
> > Hi all,
> >
> > Brian, whether to maintain the document standalone was discussed by the WG.
> You may refer, for example, to the message from Deborah which clarifies this
> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
> of the outcomes of that discussion is to add an "updates" header to 8113bis.
> >
> > FWIW, one of the issues that led to that conclusion was whether to cite
> rfc8113bis as normative in 6833bis (the approach I initially supported) and
> agreed by Dino (https://www.ietf.org/mail-
> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
> 8113bis will lead to circular dependency. Which is a fair argument.
> >
> > The "updates" tag was justified as follows:
> >
> > (1)
> >
> > RFC6833bis includes the following:
> >
> >   Values in the "Not Assigned" range can be assigned according to
> >   procedures in [RFC8126].
> >
> > That text is updated by RFC8113bis to be aligned with 8113:
> >
> >   Values can be assigned via Standards Action
> >
> > (2)
> >
> > RFC8113bis extends the type field to grab more bits/values when the
> available types are exhausted. This is captured in 8113bis:
> >
> >   The values in the range 0-1023 are assigned via Standards Action.
> >   This range is provisioned to anticipate, in particular, the
> >   exhaustion of the LISP Packet types.
> >
> > Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the
> "updates" header because (2) can be also seen as an extension.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Dino Farinacci [mailto:farina...@gmail.com]
> >> Envoyé : mercredi 19 décembre 2018 06:37
> >> À : Joel M. Halpern
> >> Cc : Brian E Carpenter; gen-art@ietf.org; l...@ietf.org; draft-ietf-lisp-
> >> rfc8113bis@ietf.org
> >> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-
> 01
> >>
> >> Mohmad to comment.
> >>
> >> Dino
> >>
> >>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
> >>>
> >>> That is the other fix he offered.  Just remove the updates tag.
> >>> I will leav eit to you and the the authors to determine which is correct.
> >>> Yours,
> >>> Joel
> >>>
> >>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>  8113bis should say that is it *extending* the type field so we can have
> >> more types. The word “update” I always had a problem with because it can
> be
> >> interpreted as “replacing". Replacing something to fix a problem.
>  8113 is simply asking for one of the type value codepoint, so there can
> be
> >> another format to have more types.
>  Dino
> > On Dec 18, 2018, at 9:24 PM, Joel M. Halpern 
> wrote:
> >
> > Authors: that sounds like a reasonable addition to me?
> >
> > Yours,
> > Joel
> >
> > On 12/18/18 10:48 PM, Brian E Carpenter wrote:
> >> On 2018-12-19 15:46, Joel M. Halpern wrote:
> >>> This is part of the package to move the coherent set of base LISP
> specs
> >>> to PS.
> >>>
> >>> The reason we did this rather than folding it into 6830bis / 6833bis
> is
> >>> that we had originally simply cited 8113, and then realized that
> needed
> >>> to move to PS along with everything else.  It seemed (and is) simpler
> >> to
> >>> do it separately rather than to further modify 6830bis / 6933bis.
> >>>
> >>> As for why it updates 6833bis, that is because one of the cahnges in
> >>> moving the set to PS was to improve the split as to which information
> >>> belonged in which document.
> >> OK, but I still don't find it logical The text doesn't explain which
> >> part of
> >> 6833bis is impacted, and normally these days we require such an
> >> explanation.
> >> And if there is an impact, you're missing the opportunity of fixing
> the
> >> error
> >> or gap in 6833bis, so the reader of 6833bis will be none the wiser
> >> unless
> >> you insert a reference to 8113bis.
> >> On the other hand, if there is no error or gap, you don't need
> >> "Updates:"
> >> at all. (Unfortunately, we don't have an "Extends:" header.)
> >>   Brian
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 12/18/18 9:25 PM, Brian Carpenter wrote:
>  Reviewer: Brian Carpenter
>  Review result: Ready with Issues
> 
>  Gen-ART 

[Gen-art] Gen-ART Last Call review of draft-ietf-extra-sieve-special-use-04

[Meral Shirazipour]

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-extra-sieve-special-use-04

Reviewer: Meral Shirazipour
Review Date: 2018-12-19
IETF LC End Date: 2018-12-20
IESG Telechat date: NA


Summary: This draft is ready to be published as Standards Track RFC .

Major issues:

Minor issues:

Nits/editorial comments:


Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-ntp-bcp-10

[Denis Reilly]

Hello, Robert! Thanks for your review.

Your comments prompted one more read-through of the draft, with specific 
attention to your points, both to be more specific with actors and to refine 
the 2119 keywords. Karen O'Donoghue has been very helpful in helping us sort 
this out, and you can expect everything to be tighter in the next revision.

Also, your point specifically about the sentence
"If the time
on your network has to be correct close to 100% of the time, then even if you
are using a satellite-based system, operators need to plan for those rare
instances when the system is unavailable (or wrong!)."

We plan on changing this to:
Depending on the application requirements, operators may need to consider 
backup scenarios in the rare circumstance when the satellite system is faulty 
or unavailable.

Best Regards,

--
Denis Reilly  |  Technical Lead  |  denis.rei...@orolia.com  (585)321-5837

-Original Message-
From: Robert Sparks  
Sent: Thursday, December 13, 2018 6:12 PM
To: gen-art@ietf.org
Cc: n...@ietf.org; draft-ietf-ntp-bcp@ietf.org; i...@ietf.org
Subject: Genart telechat review of draft-ietf-ntp-bcp-10

Reviewer: Robert Sparks
Review result: Ready with Nits

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-ntp-bcp-10
Reviewer: Robert Sparks
Review Date: 2018-12-13
IETF LC End Date: 2018-10-08
IESG Telechat date: 2018-12-20

Summary: Ready (but with nits that should be considered) for publication as a 
BCP RFC

Nits/editorial comments:

With a couple of exceptions, the changes between -07 and -10 are very helpful - 
the document reads much more naturally.

One of the changes was to be more specific with actors - many uses of "you" or 
"your" were replaced with "the operator" for example. But this wasn't done 
throughout the document ("you" and "your" still appear frequently), and in at 
least one place the change caused a sentence to stop making sense: "If the time 
on your network has to be correct close to 100% of the time, then even if you 
are using a satellite-based system, operators need to plan for those rare 
instances when the system is unavailable (or wrong!)."

I strongly encourage yet another pass focusing on removing "you" and "your" to 
the extent possible.

The changes also included using 2119 keywords much more often. Unfortunately 
many of the new uses are not appropriate. "Vendors MUST" and several instances 
of "It is RECOMMENDED" are particularly jarring. Moving 2119 to be an 
Informational reference is also incorrect if you are going to use those terms 
in this document.


ATTENTION: This email came from an external source.
Do not open attachments or click on links from unknown senders or unexpected 
emails.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

What does fixing in (1) mean?

Dino

> On Dec 19, 2018, at 3:51 AM,  
>  wrote:
> 
> Hi all, 
> 
> Brian, whether to maintain the document standalone was discussed by the WG. 
> You may refer, for example, to the message from Deborah which clarifies this 
> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One 
> of the outcomes of that discussion is to add an "updates" header to 8113bis.
> 
> FWIW, one of the issues that led to that conclusion was whether to cite 
> rfc8113bis as normative in 6833bis (the approach I initially supported) and 
> agreed by Dino 
> (https://www.ietf.org/mail-archive/web/lisp/current/msg07882.html). Deborah 
> convinced me that citing 8113bis will lead to circular dependency. Which is a 
> fair argument. 
> 
> The "updates" tag was justified as follows:
> 
> (1)
> 
> RFC6833bis includes the following:
> 
>   Values in the "Not Assigned" range can be assigned according to
>   procedures in [RFC8126].
> 
> That text is updated by RFC8113bis to be aligned with 8113: 
> 
>   Values can be assigned via Standards Action
> 
> (2) 
> 
> RFC8113bis extends the type field to grab more bits/values when the available 
> types are exhausted. This is captured in 8113bis:
> 
>   The values in the range 0-1023 are assigned via Standards Action.
>   This range is provisioned to anticipate, in particular, the
>   exhaustion of the LISP Packet types.
> 
> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the 
> "updates" header because (2) can be also seen as an extension. 
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Dino Farinacci [mailto:farina...@gmail.com]
>> Envoyé : mercredi 19 décembre 2018 06:37
>> À : Joel M. Halpern
>> Cc : Brian E Carpenter; gen-art@ietf.org; l...@ietf.org; draft-ietf-lisp-
>> rfc8113bis@ietf.org
>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>> Mohmad to comment.
>> 
>> Dino
>> 
>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
>>> 
>>> That is the other fix he offered.  Just remove the updates tag.
>>> I will leav eit to you and the the authors to determine which is correct.
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
 8113bis should say that is it *extending* the type field so we can have
>> more types. The word “update” I always had a problem with because it can be
>> interpreted as “replacing". Replacing something to fix a problem.
 8113 is simply asking for one of the type value codepoint, so there can be
>> another format to have more types.
 Dino
> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
> 
> Authors: that sounds like a reasonable addition to me?
> 
> Yours,
> Joel
> 
> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>> On 2018-12-19 15:46, Joel M. Halpern wrote:
>>> This is part of the package to move the coherent set of base LISP specs
>>> to PS.
>>> 
>>> The reason we did this rather than folding it into 6830bis / 6833bis is
>>> that we had originally simply cited 8113, and then realized that needed
>>> to move to PS along with everything else.  It seemed (and is) simpler
>> to
>>> do it separately rather than to further modify 6830bis / 6933bis.
>>> 
>>> As for why it updates 6833bis, that is because one of the cahnges in
>>> moving the set to PS was to improve the split as to which information
>>> belonged in which document.
>> OK, but I still don't find it logical The text doesn't explain which
>> part of
>> 6833bis is impacted, and normally these days we require such an
>> explanation.
>> And if there is an impact, you're missing the opportunity of fixing the
>> error
>> or gap in 6833bis, so the reader of 6833bis will be none the wiser
>> unless
>> you insert a reference to 8113bis.
>> On the other hand, if there is no error or gap, you don't need
>> "Updates:"
>> at all. (Unfortunately, we don't have an "Extends:" header.)
>>   Brian
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 9:25 PM, Brian Carpenter wrote:
 Reviewer: Brian Carpenter
 Review result: Ready with Issues
 
 Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
 
 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-lisp-rfc8113bis-01.txt
 Reviewer: Brian Carpenter
 Review Date: 2018-12-19
 IETF LC End Date: 2018-12-27
 IESG Telechat date:
 
 Summary: Ready with issues
 
 
 Comments:
 

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

> IMHO we just drop the “update 6833bis” and we are fine.

I agree.

Dino

___
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-perc-double-10

[Richard Barnes]

Thanks for the review, Russ.  Comments below (nothing major); pull request
here for your review:

https://github.com/ietf/perc-wg/pull/163

On Sat, Oct 20, 2018 at 4:24 AM Russ Housley  wrote:

> Reviewer: Russ Housley
> 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-perc-double-10
> Reviewer: Russ Housley
> Review Date: 2018-10-20
> IETF LC End Date: 2018-11-01
> IESG Telechat date: unknown
>
> Summary: Almost Ready
>
>
> Major Concerns:
>
> Section 10: Doesn't the IANA registry needs to specify the PRF to be
> used with the ciphersuite as well?
>

I don't think so.  I don't see a slot in the relevant registry for that,
and the tabular summary in the IANA considerations section is really just a
courtesy.

https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml#srtp-protection-1


>
> Minor Concerns:
>
> Section 3: It would be useful to explain the Master Key before the
> reader gets to Section 3.1.
>

Note that the "master key" concept comes from SRTP.  I've added a bit of
text to clarify.



> Section 3.1: It is unclear what assistance is provided by the
> additional level of indirection:
>
>  PRF_double_n(k_master,x) = PRF_inner_(n/2)(k_master,x) ||
> PRF_outer_(n/2)(k_master,x)
>
>  PRF_inner_n(k_master,x)  = PRF_n(inner(k_master),x)
>  PRF_outer_n(k_master,x)  = PRF_n(outer(k_master),x)
>
> It could just say:
>
>  PRF_double_n(k_master,x) = PRF_(n/2)(inner(k_master),x) ||
> PRF_(n/2)(outer(k_master),x)
>



Not sure what I was thinking.



> Section 4: I suggest:
>
> If the marker bit is not present, then B MUST be set to zero.
>




> Section 5, 1st paragraph: and endpoint cannot verify confidentiality.
>

Well, it can verify that the packet was encrypted with a key known only to
the endpoints.  But OK.


>
> Nits:
>
> The document uses "encryption" and "confidentiality" interchanagably.
> Encryption is a mechanism or algorithm.  Confidentiality is a security
> service.  While I do not think that the reader will be confused by the
> current wording, it would be better to use the terms properly.  In
> addition, it is misleading to say:
>
>... the receiving endpoint that can encrypt and authenticate ...
>
> because the sending endpoint encrypts, and the recieving endpoints
> decrypts.  Also, the receiving endpoints check the authentication tag.
>

That's actually just some bad grammar.  Reworded.



> Abstract: s/authenticated encryption with associated data/
>/authenticated encryption with associated data (AEAD)/
>
> Abstract: s/scheme/algorithm/
>
> Section 5.2: s/GCM/AES-GCM/
>
> Section 7: s/HBH/hop-by-hop/
>
> Section 7: s/E2E/end-to-end/
>
> Section 7.1: s/HBH/hop-by-hop/
>
> Section 7.2: The text is redundant.  I suggest "etc" be dropped from
> "such as SSRC, SEQ, CSRC, etc"
>
> Section 7.2: s/non primary/non-primary/
>
> Section 7.3: s/HBH/hop-by-hop/
>

Implemented all of the above...


> Appendix A: s/HBH/hop-by-hop/
>
> Appendix A: s/E2E/end-to-end/
>

 but I'm going to leave these last two as-is, for brevity.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05

[Pete Resnick]

Reviewer: Pete Resnick
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-bess-evpn-vpls-seamless-integ-0
Reviewer: Pete Resnick
Review Date: 2018-12-19
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with some nits, but one process issue/query.

Major issues: None

Minor issues:

This document is intended for Proposed Standard. It doesn't have protocol as
much as operational configuration information for integration. RFC 2026 section
5 says:

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.
   [...]
   Historically Internet standards have generally been concerned with
   the technical specifications for hardware and software required for
   computer communication across interconnected networks.  However,
   since the Internet itself is composed of networks operated by a great
   variety of organizations, with diverse goals and rules, good user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.

That sounds like what this document is doing. It also sounds like this document
is unlike to advance to Internet Standard, as there's not the kind of iterative
implementation that protocols go through. It's not a big deal either way, but
this does seem better suited to a BCP.

Nits/editorial comments:

Abstract: s/draft/document/g

Introduction: "Many Service Providers (SPs) who...". You don't use "SP"
anywhere else in the document, and other places where you use the phrase it
isn't capitalized. Suggest just saying "Many service providers who..."

§1, Definitions:

   (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. As for EVPN, this
   abbreviation is used when the text applies to both technologies.

It says EVPN in the second sentence. I don't understand. Did you mean VPLS?

§2: The 4 "MUST"s and 1 "MAY" aren't requirements on the implementation;
they're the requirements this document will satisfy. Seems like they shouldn't
be capitalized.

§3.2, second bullet, 3.4.1, last paragraph, §4.2, second bullet, and §4.4.1,
last paragraph: Why are the "must"s not capitalized?


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

[Gen-art] Genart last call review of draft-ietf-sipcore-sip-push-21

[Stewart Bryant]

Reviewer: Stewart Bryant
Review result: Ready with Nits

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-sipcore-sip-push-21
Reviewer: Stewart Bryant
Review Date: 2018-12-19
IETF LC End Date: 2018-12-21
IESG Telechat date: Not scheduled for a telechat

Summary: A well written document with some minor points that could use a little
attention.

Major issues: None

Minor issues:

In Figure 1 the following is included:

 REGISTER sip:al...@example.com SIP/2.0
 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
 Max-Forwards: 70
 To: Alice 
 From: Alice ;tag=456248
 Call-ID: 843817637684230@998sdasdh09
 CSeq: 1826 REGISTER
 Contact: 
 Expires: 7200
 Content-Length: 0

SB> However I don't at this stage of the text see the relationship between the
packet flow digram and the text that follows.

=
   Contact: IESG (i...@ietf.org)

SB> Is the whole IESG the most appropriate first point of contact?

=

Nits/editorial comments:
Presumably the references to RFC  will be replaced by RFC  but
that does not seem to be noted in the text



   As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must
SB> Typo s/dicussed/discussed/



   Example: pn-prid = 00fc13adff78512

   For more information about the APNs Topic and device token:

SB> Is the following part of the example? If so it could usefully be delimited
as SB>  such, otherwise, I don't understand why it is not a normal document
 SB> reference.

   https://developer.apple.com/library/archive/documentation/NetworkingI
   nternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html

SB> Similarly in the following section
=


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

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[mohamed.boucadair]

Hi all, 

Brian, whether to maintain the document standalone was discussed by the WG. You 
may refer, for example, to the message from Deborah which clarifies this point: 
https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One of the 
outcomes of that discussion is to add an "updates" header to 8113bis.

FWIW, one of the issues that led to that conclusion was whether to cite 
rfc8113bis as normative in 6833bis (the approach I initially supported) and 
agreed by Dino 
(https://www.ietf.org/mail-archive/web/lisp/current/msg07882.html). Deborah 
convinced me that citing 8113bis will lead to circular dependency. Which is a 
fair argument. 

The "updates" tag was justified as follows:

(1)

RFC6833bis includes the following:
 
   Values in the "Not Assigned" range can be assigned according to
   procedures in [RFC8126].

That text is updated by RFC8113bis to be aligned with 8113: 

   Values can be assigned via Standards Action

(2) 

RFC8113bis extends the type field to grab more bits/values when the available 
types are exhausted. This is captured in 8113bis:

   The values in the range 0-1023 are assigned via Standards Action.
   This range is provisioned to anticipate, in particular, the
   exhaustion of the LISP Packet types.

Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the 
"updates" header because (2) can be also seen as an extension. 

Cheers,
Med

> -Message d'origine-
> De : Dino Farinacci [mailto:farina...@gmail.com]
> Envoyé : mercredi 19 décembre 2018 06:37
> À : Joel M. Halpern
> Cc : Brian E Carpenter; gen-art@ietf.org; l...@ietf.org; draft-ietf-lisp-
> rfc8113bis@ietf.org
> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
> 
> Mohmad to comment.
> 
> Dino
> 
> > On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
> >
> > That is the other fix he offered.  Just remove the updates tag.
> > I will leav eit to you and the the authors to determine which is correct.
> > Yours,
> > Joel
> >
> > On 12/18/18 11:43 PM, Dino Farinacci wrote:
> >> 8113bis should say that is it *extending* the type field so we can have
> more types. The word “update” I always had a problem with because it can be
> interpreted as “replacing". Replacing something to fix a problem.
> >> 8113 is simply asking for one of the type value codepoint, so there can be
> another format to have more types.
> >> Dino
> >>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
> >>>
> >>> Authors: that sounds like a reasonable addition to me?
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>  On 2018-12-19 15:46, Joel M. Halpern wrote:
> > This is part of the package to move the coherent set of base LISP specs
> > to PS.
> >
> > The reason we did this rather than folding it into 6830bis / 6833bis is
> > that we had originally simply cited 8113, and then realized that needed
> > to move to PS along with everything else.  It seemed (and is) simpler
> to
> > do it separately rather than to further modify 6830bis / 6933bis.
> >
> > As for why it updates 6833bis, that is because one of the cahnges in
> > moving the set to PS was to improve the split as to which information
> > belonged in which document.
>  OK, but I still don't find it logical The text doesn't explain which
> part of
>  6833bis is impacted, and normally these days we require such an
> explanation.
>  And if there is an impact, you're missing the opportunity of fixing the
> error
>  or gap in 6833bis, so the reader of 6833bis will be none the wiser
> unless
>  you insert a reference to 8113bis.
>  On the other hand, if there is no error or gap, you don't need
> "Updates:"
>  at all. (Unfortunately, we don't have an "Extends:" header.)
> Brian
> >
> > Yours,
> > Joel
> >
> > On 12/18/18 9:25 PM, Brian Carpenter wrote:
> >> Reviewer: Brian Carpenter
> >> Review result: Ready with Issues
> >>
> >> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
> >>
> >> 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-lisp-rfc8113bis-01.txt
> >> Reviewer: Brian Carpenter
> >> Review Date: 2018-12-19
> >> IETF LC End Date: 2018-12-27
> >> IESG Telechat date:
> >>
> >> Summary: Ready with issues
> >> 
> >>
> >> Comments:
> >> -
> >>
> >> I note that this is being raised from Experimental to the standards
> track.
> >> Presumably that depends on the base LISP spec becoming PS.
> >>
> >> Minor 

Re: [Gen-art] [bess] Genart last call review of draft-ietf-bess-evpn-df-election-framework-06

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Francesca,

Thank you very much for your review.
Please see in-line how we are resolving your comments in the next revision (07, 
to be published asap).

Thanks.
Jorge

-Original Message-
From: BESS  on behalf of Francesca Palombini 

Date: Friday, December 14, 2018 at 5:13 PM
To: "gen-art@ietf.org" 
Cc: "draft-ietf-bess-evpn-df-election-framework@ietf.org" 
, "i...@ietf.org" 
, "b...@ietf.org" 
Subject: [bess] Genart last call review of 
draft-ietf-bess-evpn-df-election-framework-06

Reviewer: Francesca Palombini
Review result: Ready with Nits

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-bess-evpn-df-election-framework-06
Reviewer: Francesca Palombini
Review Date: 2018-12-14
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Major issues: N/A

Minor issues:

I agree with the reviewers comments saying that this document should update
RFC7432 and RFC8124. In particular, quoting RFC2232
(https://tools.ietf.org/html/rfc2223#section-12):

   [...] A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the previously
   existing document, and has limited usefulness independently.  The
   terms Supercedes and Replaces are no longer used.

   Updates

  To be used as a reference from a new item that cannot be used
  alone (i.e., one that supplements a previous document), to refer
  to the previous document.  The newer publication is a part that
  will supplement or be added on to the existing document; e.g., an
  addendum, or separate, extra information that is to be added to
  the original document.

(Yes, RFC2232 is obsolete, but I could not find the same text in the more
recent RFC7322)

[JORGE] I think this document "can stand on its own" and it is "useful 
independently" of RFC7432, although the latter document is a normative 
reference of course. Please see the resolution to Adrian's comment: 
https://www.ietf.org/mail-archive/web/bess/current/msg03760.html 
Martin, please let us know if you are not okay with our resolution.


Nits/editorial comments:

  "but they do not require
   any changes to the EVPN Route exchange and have minimal changes to
   their content per se."

* what does their refer to?
[JORGE] changed to the following for clarity:
"These mechanisms do involve changes to the Default DF Election algorithm, but 
they do not require any changes to the EVPN Route exchange and have minimal 
changes in the EVPN routes."

* Section 2.2.2: expand MAC-VRF on first usage for readability (or add a
reference to its definition)
[JORGE] added to the terminology section.

* Figure 3: add a definition for ANY STATE (the figure is clear, but for
consistency I would add that in the text as well)
[JORGE] Added:
"5.  ANY_STATE: Refers to any of the above states."

* Figure 3: add "or" between VLAN_CHANGE, RCVD_ES, LOST_ES (again, not
necessary, suggested for readability of the figure)
[JORGE] done, thx

* Section 3.1: the term "re-entering" needs clarifying: I would consider a 
loop
as re-entering the state, but from bullet 8. it seems like you don't.
[JORGE] good point. Changed 8 to:
"8.  DF_CALC on VLAN_CHANGE, RCVD_ES or LOST_ES: do *as in transition 
7.**"

* suggestion for figure 4 (otherwise it looks like there are 2 fields 
Bitmap of
1B each):

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=0x06 | Sub-Type(0x06)| RSV |  DF Alg |Bitmap ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~   |Reserved   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[JORGE] done, thanks.


* Section 3.2: why was Bit 0 left unassigned in Bitmap?
[JORGE] there are implementations of 
https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-02 using that bit.

* IANA considerations: I think you want to specify that the policy for Alg 
31
is Experimental use (right now the text describing the policy only says "RFC
required", with no distinction for different values).
[JORGE] ok, done.