Re: [Gen-art] Genart last call review of draft-uberti-rtcweb-rfc8829bis-02

[Joel M. Halpern]

Thanks Sean.  I finally concluded that was the intent.  And I think 
technically it says so.
If you could look at making that more clear early, it would probably 
help those readers who are not as familiar with the cited W3C API.


Yours,
Joel

On 3/28/2022 10:47 PM, Sean Turner wrote:




On Mar 27, 2022, at 13:49, Joel Halpern via Datatracker  
wrote:

Reviewer: Joel Halpern
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-uberti-rtcweb-rfc8829bis-02
Reviewer: Joel Halpern
Review Date: 2022-03-27
IETF LC End Date: 2022-04-05
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed Standard.
However, there are some issues that should be considered before final approval.

Major issues: None

Minor issues:
I found myself confused as a reader about one aspect of this document  The
document seems to describe both the Interface to the JSEP and the details
of what the underlying system must do in response to JSEP operations.  The
later is described very well and clearly.  The former is described quite
vaguely.  I suspect that the assumption is that the required parameters are
described in the W3C documents.  But it is hard to tell, and the only
formal reference is a vague citation in the introduction to an outdated W3C
specification.  A little more clarity on how an implementor is supposed to
know what actual interface objects, methods, and parameters they need to
provide would be helpful.  Also, the reference should be updated to
whatever is the current W3C specification.


Will check on updating the reference. I would be floored if we couldn’t point 
to it.

The basic idea here is that the W3C WebRTC spec is API and this is the protocol 
spec.


Nits/editorial comments:







___
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-opsawg-vpn-common-09

[Joel M. Halpern]

Thank you for the clarifications Med.  That all seems good.

Yours,
Joel

On 9/3/2021 8:38 AM, mohamed.boucad...@orange.com wrote:

Hi Joel,

Thank you for the review.

Please see inline.

Cheers,
Med


-Message d'origine-
De : Joel Halpern via Datatracker [mailto:nore...@ietf.org]
Envoyé : vendredi 30 juillet 2021 18:38
À : gen-art@ietf.org
Cc : draft-ietf-opsawg-vpn-common@ietf.org; last-c...@ietf.org;
ops...@ietf.org
Objet : Genart last call review of draft-ietf-opsawg-vpn-common-09

Reviewer: Joel Halpern
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-opsawg-vpn-common-09
Reviewer: Joel Halpern
Review Date: 2021-07-30
IETF LC End Date: 2021-08-06
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed
Standard RFC

Major issues: N/A

Minor issues:
 I just want to confirm that one form of reference is normal for
YANG
 models?  There are a few identities whose meaning is defined by
I-Ds that
 are under way.  The references section of the identity gives the
I-D name.
 Which is fine.  The references at the bottom of the document
makes those
 informative references.  That seems a little odd since those
references are
 necessary to understand the meaning of those identities.  Is
this a normal
 practice for YANG models?


[Med] I confirm. We are following this part from RFC8407:

 " If a YANG module
   contains reference or "description" statements that refer to an
   I-D, then the I-D is included as an informative reference. "


  I am a little confused as to why the srv6 identity includes in
its
  references clause RFC 8663 (MPLS SR).  Is this a copy-and-paste
error?


[Med] Please note that we are referring RFC8663, not RFC8660. This is because 
we assumed that RFC8663 uses IPv6 as an underlay, but that's may be confusing.

I suggest to go with this change:

OLD:
   identity srv6 {
 base sr;
 description
   "Transport is based on SR over IPv6.";
 reference
   "RFC 8663: MPLS Segment Routing over IP
RFC 8754: IPv6 Segment Routing Header (SRH)";
   }

NEW:
   identity srv6 {
 base sr;
 description
   "Transport is based on SR over IPv6.";
 reference
   "RFC 8754: IPv6 Segment Routing Header (SRH)";
   }

   identity sr-mpls-over-ip {
 base sr;
 description
   "Transport is based on SR over MPLS over IP.";
 reference
   "RFC 8663: MPLS Segment Routing over IP";
   }

Please let me know if this is better. Thanks.


 I hope I am misreading the qos-classification-policy definition.
It
 appears to have an id, a match rule, and a match action.   The
match rule
 can be a match-flow or a match-application.  So far, so good.
(putting
 aside the nit below on customer-application.)   But the match
rule is a
 choice between an L3 and an L4 rule.


[Med] This is not a choice between these two, but each of them is a choice in 
its own. FWIW, here is an excerpt from RFC8340 to distinguish between choices 
and cases:

==
 is the name of the node
  () means that the node is a choice node
 :() means that the node is a case node
==

Things would be problematic if we defined L3/L4 as "cases" of the same choice, 
but we aren't.

   As I understand it, there

are many
 cases where the actual classification is based on a combination
of l3 and
 l4 information.  How is that to be represented?


[Med] An example to illustrate how both can be included in shown below (DNS 
traffic destined to 2001:db8::/32)

A valid rule for DNS traffic for example is shown below:

{
   "id": "a-rule-id",
   "ipv6": {
 "destination-ipv6-network": "2001:db8::/32"
   },
   "udp": {
 "destination-port-range-or-operator": {
   "operator": "eq",
   "port": 53
 }
   }
}



Nits/editorial comments:
 The "customer-application" identity seems to be asking for
problems in two
 regards.


[Med] FYI, we inherited this from service modules (RFC8299 and RFC8466) where 
these common identities are used.

 It seems that it is a shorthand way of expressing

some
 combination of protocols and ports.


[Med] This can be indeed expressed as such, but at more likely at the network 
level. We are covering both as the common module can be used by both service 
and network models.

The larger concern I have

is that
 there is no reference that explains what classification rules
should be
 used for any of the derived identities.   Which means that for
an
 interoperable implementation, there seems to be some difficulty
in ensuring
 that the client and server 

Re: [Gen-art] Genart last call review of draft-halpern-gendispatch-consensusinformational-02

[Joel M. Halpern]

Thank you Roni.
Joel

On 2/2/2020 4:10 AM, Roni Even via Datatracker wrote:

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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-halpern-gendispatch-consensusinformational-??
Reviewer: Roni Even
Review Date: 2020-02-02
IETF LC End Date: 2020-02-21
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is ready for publication as a BCP .

Noticed on the mailing list that it was already reviewed by Alissa

Major issues:

Minor issues:

Nits/editorial comments:


___
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] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11

[Joel M. Halpern]

Barry, I have a real problem with us producing a document with WG rough 
consensus, IESG approval, but not IETF rough consensus.


People have been complaining about various markings causing confusion 
about the status and meaning of documents.  This seems a MUCH worse case 
than anything I have seen.


The fact that the tooling allows it, and even presumably that IESG 
processes allow it, does not make it a good idea.


If I think about it too much, I end up unable to parse the notion of a 
document published on the IETF stream without IETF rough consensus.


Yours,
Joel

On 10/15/2019 2:19 PM, Barry Leiba wrote:

If we do not have agreement on what the meaning is for the relevant
terms, then either
1) The document should not be an IETF consensus document (which even
Informational publication is)


Just a point on this: it's not true.

We have a "consensus" flag in the datatracker, which triggers a
boilerplate change.  It's always set to "yes" for Standards Track or
BCP, but for Informational and Experimental it can be set either way.
If it's set to "no", the boilerplate says that the document does not
have IETF consensus.  It's possible that when we're done with this
document it could settle into that.

It's also possible that we might convince the regext working group to
stop processing this document and suggest to the authors to go to the
ISE.  I don't think we're there yet, and at the moment the working
group has consensus to publish it as a working group product

Barry



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

Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11

[Joel M. Halpern]

Regarding the document status, neither of the emails you pointed to 
explains why the document is Informational.  I understand from that and 
other discussions that there is no desire to make this standards track. 
 As has been noted, publication of usages of protocol by small groups 
is normally handled by the Independent Stream.  This document has been 
processed by the working group.


It is very strange for a protocol document to be processed by a working 
group, be accepted as not needing experimental status, and not be 
published as a standards track document.  Reading teh dcouemtn, I see no 
reason for it not to be standards track.


If there is concern that there may be problems with the document, then 
Experimental status would be the normal way to handle this document. 
With an explanation of what the experiment is intended to represent.


If the working group feels there is a good reason for informational 
publication, that should be document somewhere.  It is currently not 
documented in either the document itself or the shepherd report.


The fact that proprietary extensions to EPP are allowed by the protocol 
and registries is irrelevant.  This document is an IETF working group 
product and therefore is not a proprietary extension.


With regard to the "b-dn:" elements of this document, I am now more 
concerned than I was.  I had thought those were a reference to some 
other document that clearly defined the syntax and semantics of those 
elements.  I now understand that the given prefix is used for the new 
elements defined in this document.  The structure that is used to 
describe the expected and permitted content of these elements is qutie 
confusing.  The actual definition is only in the "formal syntax" 
section.  The descriptions are scattered embedded in descriptions of the 
messages, expecting to user to determine the permitted and required 
behavior from informal descriptive text.  Yes, for those who already 
know how it works and what it needs, everything is hear.  For a new 
implementor it is very hard to follow.


Yours,
Joel

PS: Replies to my concerns on the regext list that did not copy any of 
the IETF list, the genart list, or my email address were not seen by me, 
and will not be seen by me if that is chosen again.


On 10/15/2019 3:55 AM, Jiankang Yao wrote:





-原始邮件-
发件人: "Joel Halpern via Datatracker" 
发送时间: 2019-10-11 06:56:18 (星期五)
收件人: gen-art@ietf.org
抄送: draft-ietf-regext-bundling-registration@ietf.org, i...@ietf.org, 
reg...@ietf.org
主题: [regext] Genart telechat review of 
draft-ietf-regext-bundling-registration-11

Reviewer: Joel Halpern
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-regext-bundling-registration-11
Reviewer: Joel Halpern
Review Date: 2019-10-10
IETF LC End Date: None
IESG Telechat date: 2019-10-17


Dear Joel Halpern,

   Thanks a lot for your kind review.



Summary: This document is almost ready for publication as an RFC.

I have received no response to my earlier review.  Some of the items have been
addressed, but not all of them.

Major issues:
 This document clearly defines normative protocol behavior.  As such, it
 would seem to either be Experimental or Proposed Standard, but not
 Informational.



Because the WG chair clarified this issue in the mailing list after your 
review, the WG decided that this document should go to informational. I thought 
you may be clear about it.
So I did not directly response to this issue. Sorry about it. Some information 
about this issue from one of the co-chairs:

https://mailarchive.ietf.org/arch/msg/regext/wPQdna8E6eHkF4co4XDxrNzHPls#
https://mailarchive.ietf.org/arch/msg/regext/PILROKSKupLTh6tdVuye5b6ou1k




Minor issues:
 The document incorporates items from a name space
 "urn:ietf:params:xml:ns:epp:b-dn", referred to with the prefix "b-dn:".
 The only explanation of this meaning is in the terminology section.
 However, the description does not indicate what document defines this
 information.



In section 10 "IANA Considerations", the XML namesapce and schema is defined. 
IANA will add a XML registry for this document at 
https://www.iana.org/assignments/xml-registry/xml-registry.xml.
IANA is  requested to assignment the two URIs. One is 
urn:ietf:params:xml:ns:epp:b-dn.
  So the XML information can be checked on this page.

I hope that the above information can answer your concerns.

Thanks a lot.

Jiankang Yao



Nits/editorial comments:
 I note and appreciate that my comments on the SHOULD usage in section 7.2
 has been addressed.


___

Re: [Gen-art] [Iasa20] Genart last call review of draft-ietf-iasa2-rfc5377bis-02

[Joel M. Halpern]

Thank you Elwyn.  I have applied both changes to my private copy.  I 
will submit when the chairs / ADs request.


Yours,
Joel

On 8/14/2019 6:42 PM, Elwyn Davies via Datatracker wrote:

Reviewer: Elwyn Davies
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-iasa2-rfc5377bis-02
Reviewer: Elwyn Davies
Review Date: 2019-08-14
IETF LC End Date: 2019-08-14
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready with a couple of nits.  The text of  para 2 of section 3 refers to an
initial state that is not applicable to the transition which requires this
update.  Emphasising continuity seems more appropriate.

Major issues:
None

Minor issues:
None

Nits/editorial comments:
Abstract, last  sentence (very picky): Technically, what has been removed from
the text of RFC 5377 are references to the IAOC.  Suggest s/IASA/IAOC which was
part of IASA/

s3, para 2, first sentence:  The first sentence was applicable to the original
creation of the licence policies and text when responsibility was initially
transferred to the trustees and is inappropriate for the current modification
of the trust organisation.  It could probably be safely deleted, or the
continuity could be emphasised by something like... OLD:
The rough consensus described in this document reflects the agreement
of the IETF as of the IETF Last Call, and the Trustees of the IETF
Trust are to begin drafting license text and other materials to act
on these instructions upon IESG approval of this document for RFC
publication.
NEW:
To ensure continuuty, the starting point for license text and other 
materials
will be that previiysly created by the Trustees of the IETF under the
authority of [RFC5377] which this document supersedes.
ENDS
This requires a reference to RFC 5377.

___
iasa20 mailing list
ias...@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20



___
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-rmcat-nada-11

[Joel M. Halpern]

Thank you.  Those changes will address my concerns very effectively.
Yours,
Joel

On 8/13/2019 11:26 AM, Xiaoqing Zhu (xiaoqzhu) wrote:

Dear Joel,

Many thanks for your review of this draft.  Please find our responses as below, 
tagged [Authors].

Best,
Xiaoqing (on behalf of all authors)

On 8/5/19, 5:17 PM, "Joel Halpern via Datatracker"  wrote:

 Reviewer: Joel Halpern
 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-rmcat-nada-11

 Reviewer: Joel Halpern
 Review Date: 2019-08-05
 IETF LC End Date: 2019-08-12
 IESG Telechat date: Not scheduled for a telechat
 
 Summary: This document is almost ready for publication as an Experimental RFC
 
 Major issues:

It is unclear reading this RFC how the observation information is to be
communicated from the receiver to the sender.  At first I thought it 
was to
use the RTP Receiver report.  But there is no description of how to map 
the
fields to that report.   Then section 5.3 describes requirements for a
reporting mechanism, but does not seem to actually define one.   Thus, 
I am
left unclear how independent interoperable implementations of this 
draft can
be created.
 
[Authors]  Thanks for raising this point. The feedback format is a topic covered

by another currently pending draft 
(https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-04),
which indeed aims at ensuring interoperability of independent implementations of
RMCAT congestion control solutions.  Therefore, in this draft we only specified 
what type
of information is needed (e.g., receiving rate) and the unit and bit budget it 
is expressed
in (e.g., in bps in 32 bits) in the feedback from the receiver.  We also 
pointed out in Sec. 6.4
that an alternative way to implement this draft would be to leverage feedback 
messages
that contain per-packet information (e.g., delay and loss info) and to move all 
the calculations
from the receiver to the sender.

[Author] Given the above considerations, we refrained from specifying a 
specific feedback
format. However, we should perhaps add a reference pointing to the 
cc-feedback-message draft.
Will do that in the next revision.

 Minor issues:
 The document has 7 front page authors.   The shepherd writeup does not
 comment on this. The shepherd writeup seems quite sparse.  II would 
have
 expected some reference to the experimental behavior described in the 
draft.
 
[Authors] Thanks for raising the concern about long list of front page authors. We got some

additional guidance from the AD and will make some adjustments accordingly.

[Authors] As for comments on the experimental behavior: we have presented in 
recent IETF meetings
on several sets of real-world evaluations of one implementation of NADA.  But, 
admittedly, the draft
is lagging behind in not yet adding pointers to those results. Your suggestion 
is a great one and we'll add
corresponding pointer (see links below) and related discussions in the next 
version.
  
* https://datatracker.ietf.org/meeting/103/materials/slides-103-rmcat-nada-implementation-in-mozilla-browser-00

* 
https://datatracker.ietf.org/meeting/105/materials/slides-105-rmcat-nada-update-02.pdf


 This comment is just to confirm that I am reading the draft correctly. 
 It
 looks like when the observed delay cross the delay boundary, the 
reporting
 system reports using a smaller delay than actually approved (slightly 
more
 than 1/9th of observed delay when delay is 3*QTH).  I presume this is
 intentional, and that the various analysis pointed to evaluate the 
risks of
 such false reporting?

[Authors]  Yes, your understanding is correct. The main motivation for this "delay 
warping"
In the presence of persistently high queuing delay *and* presence of loss is to 
help the flow to
sustain a more fair rate when competing against aggressive loss-based flows.  
Will follow your
advice and add some discussions on the potential risks involved in performing this 
"delay warping".
 
 Is it intentional in section 4.3 in the pseudo-code that the rate clipping

 (to keep the rate between RMIN and RMAX) is only applied to the gradual
 rate change, not to the accelerated rate change?  The later code says 
that
 the clipping is always applied, which is what I would expect.
 
[Authors]  Thanks to the catch. The clipping is always applied.  Will fix the text accordingly.


 Nits/editorial comments:
 
 
[Authors]  

Re: [Gen-art] Genart last call review of draft-klensin-idna-unicode-review-02

[Joel M. Halpern]

No problem on the time.  I appreciated Barry's ack.
Further on your response below.
Yours,
Joel

On 8/10/2019 2:13 AM, John C Klensin wrote:

Joel,

My apologies for not being able to respond to this sooner.  I've
been preoccupied for the last couple of days with some non-IETF
matters.  Inline below.

--On Thursday, August 8, 2019 19:23 -0700 Joel Halpern via
Datatracker  wrote:


Reviewer: Joel Halpern
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-klensin-idna-unicode-review-02
Reviewer: Joel Halpern
Review Date: 2019-08-08
IETF LC End Date: 2019-08-30
IESG Telechat date: Not scheduled for a telechat

Summary: THis document is ready for publication as a Proposed
Standard

 This reviewer found the document quite readable and clear
about what it was doing (with one minor issue noted
below.)  The reviewer does not have the background to
evaluate whether the technical substance is correct or
incorrect, and leaves that to the community review.  The
document is quite persuasive.

Major issues: N/A


Thanks for what was obviously a careful reading.


Minor issues:
 I would like to see a little more explicit text in section
3.2.  It was not until I reached the IANA considerations
(section 8) that I realized that section 3.2 intended to
mandate that the IESG create and where applicable use a
broad review team for the new code point review.  I think a
sentence or so along the lines of "Creation of this team
when needed is a new responsibility placed on the IESG by
this document." would have helped.


While I don't think that text (or something like it) would be
harmful and will happily include it in the I-D if Barry and the
IESG think it would help, you have, from my standpoint,
uncovered the elephant in the room.  It may be a mean-tempered
elephant.

The difficulty with i18n work is that it requires people to work
together to combine the perspectives of multiple specialties.
Of course, the same could be said for routing or security, but
most of the relevant specialties are part of, or align well
with, expertise that are moderately common in, or that seem to
fit  well with, the IETF.   With i18n, many are not and they
rarely appear, all together, in on person.   So competent review
of just about anything in internationalization in the IETF
requires a team.  The IESG has known that since 2003 or earlier
and took on the responsibility then.   When we've appointed a
single Designated Expert, it has almost always been someone who
is expected to reach out to others, collect opinions, and then
synthesize a result (again, really not so different from many
other topic areas).  So, really, this I-D is not changing much
of anything in terms of what was expected, it is just being a
tad more explicit about it.

In addition, I predict that it will be fairly rare for the IESG
to have sufficient internal expertise and contacts to recruit
and select an entire team with the right mix of skills.
Remember that, because some of the skills are uncommon in the
IETF, a note to the IETF list or former WG lists asking for
volunteers may not be productive.  Certainly IESGs with the full
range of needed knowledge have not been common in the last
decade or so.  So I'd predict that a sensible IESG would pick
one or two people, ask them to recruit a team, and then bring
the list of team members back to the IESG for a sanity check.
It is probably not a coincidence that almost that model was used
by the ART ADs to set up the i18n Directorate, nor, if the
Directorate continues, would it surprise me if "the team" turned
out to be the Directorate or a selected subset of it.

If we are going to make the language more precise as you
suggest, we need to do it so as to not constrain the IESG's
ability to pick any of those options that makes sense in a given
year.



While one can argue that the meaning you want is implicit in the current 
text, I do not think most readers will get it.  And thus and IESG 
without your context might easily not get it either.  Would the 
following three sentences work?

This document makes more explicit the IESG responsibility to ensure
a proper review team for the new code point review.  As that team
needs a broad range of skills, the IESG may use a range of
strategies to populate the team.   In particular, the IESG may
select an individual to do the work of proposing a sufficiently
broad team for the review, and then empower that team.


best,
john




Nits/editorial comments: N/A









___
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-lamps-pkix-shake-08

[Joel M. Halpern]

The latest version (which I reviewed yesterday) has the assignments.
Joel

On 6/25/19 12:27 PM, Alissa Cooper wrote:

Joel, thanks for your reviews. I entered a No Objection ballot. I trust that 
the identifier assignments will work out with NIST.

Alissa


On Mar 31, 2019, at 1:28 AM, Joel M. Halpern  wrote:

Maybe a note that the assignment will take place once the drafts are approved, and that the RFC 
should coordiante with the authors and NIST on this?  (I presume we have done this before, and we 
do not have the problem we have in some other cases of "no number until RFC" / "no 
RFC until number".)

Yours,
Joel

On 3/31/19 1:21 AM, Russ Housley wrote:

On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker  
wrote:

Reviewer: Joel Halpern
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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-pkix-shake-08
Reviewer: Joel Halpern
Review Date: 2019-03-30
IETF LC End Date: 2019-04-10
IESG Telechat date: Not scheduled for a telechat

Summary: This document is almost ready for publication as a Proposed Standard

Major issues:
One of the key points of this RFC seems to be to assign the identifiers for
the use of the two SHAKE variants.  It is thus confusing that the
identifiers end with "TBD", and thus are not defined in this document.

They will be assigned by NIST once they are sure that these are the identifiers 
that we want.  This is much the same as we do when IANA is ti assign the 
identifier.
Russ


___
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] Genart last call review of draft-ietf-lamps-pkix-shake-08

[Joel M. Halpern]

Maybe a note that the assignment will take place once the drafts are 
approved, and that the RFC should coordiante with the authors and NIST 
on this?  (I presume we have done this before, and we do not have the 
problem we have in some other cases of "no number until RFC" / "no RFC 
until number".)


Yours,
Joel

On 3/31/19 1:21 AM, Russ Housley wrote:




On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker  
wrote:

Reviewer: Joel Halpern
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-lamps-pkix-shake-08
Reviewer: Joel Halpern
Review Date: 2019-03-30
IETF LC End Date: 2019-04-10
IESG Telechat date: Not scheduled for a telechat

Summary: This document is almost ready for publication as a Proposed Standard

Major issues:
One of the key points of this RFC seems to be to assign the identifiers for
the use of the two SHAKE variants.  It is thus confusing that the
identifiers end with "TBD", and thus are not defined in this document.


They will be assigned by NIST once they are sure that these are the identifiers 
that we want.  This is much the same as we do when IANA is ti assign the 
identifier.

Russ



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

Re: [Gen-art] [regext] Genart last call review of draft-ietf-regext-bundling-registration-09

[Joel M. Halpern]

While the status is between you and the IESG, in my experience it is 
very unusual for the IETF to define a protocol in an Informational RFC. 
(I presume there are some exceptions.)  The obvious move if the WG does 
not want to publish it as standards track is to publish as an 
experimental RFC.


Failing that, I hope that you have provided more justification than 
"this is what the WG chose" to your area director.


I look forward to seeing the reolution on the other comments.

Yours,
Joel

On 3/14/19 11:16 PM, Jiankang Yao wrote:





-原始邮件-
发件人: "Joel Halpern via Datatracker" 
发送时间: 2019-03-08 07:33:32 (星期五)
收件人: gen-art@ietf.org
抄送: draft-ietf-regext-bundling-registration@ietf.org, i...@ietf.org, 
reg...@ietf.org
主题: [regext] Genart last call review of 
draft-ietf-regext-bundling-registration-09

Reviewer: Joel Halpern
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-regext-bundling-registration-09
Reviewer: Joel Halpern
Review Date: 2019-03-07
IETF LC End Date: 2019-03-15
IESG Telechat date: Not scheduled for a telechat

Summary: This document is almost ready for publication as some form of RFC



Thanks for your kind review.


Major issues:
 This document defines protocol extensions and mandatory procedures to go
 with them.  As such, it seems it is either Experimental or Proposed
 Standard, but not Informational.



This document was originally for proposed standard. After WG's discussion, the 
WG decides to move it as informational.



Minor issues:
 Section 5 consists of a list of behavioral requirements that appear
 normative, but do not use RFC 2119 language.  If these are indeed normative
 behavioral requirements, the document should use RFC 2119 language to be
 clear.  (And therefore, should also include the text explaining and citing
 RFC 2119.)



Yes, will update it.



The description in 7.2.1 of the EPP  command seems lacking.  After
saying that it needs an extension element, it says:
 The  element SHOULD contain a child  element
 that identifies the bundle namespace and the location of the bundle
 name schema.
It is unclear when it is reasonable to omit this  element.  (We
normally include with "SHOULD" explanations of this sort.) It is unspecified
what format of the information in the  element has.  I suspect
that it is assumed to be the same as some other piece of EPP information, but
it does not say so.  The only child element for  given in the
schema is the  which is neither a namespace identifier nor a location
of the bundle name schema.



Thanks. We will consider to update it.



 Again in 7.2.2 on the EPP  command, when discussing the addition to
 the response, it is a SHOULD with no explanation of when it is okay to omit
 it.  The same applies to the 7.2.3 EPP  command, the 7.2.4 EPP
  command, and the 7.2.5 EPP  command.



Thanks. We will consider to change it to "MUST" or add some explanations.


Best Regards.

Jiankang Yao

Nits/editorial comments:


___
regext mailing list
reg...@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
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] Genart last call review of draft-ietf-detnet-architecture-08

[Joel M. Halpern]

Thank you Janos.  I have looked at the changes.  They address my 
concerns, and make a number of other useful and consistent changes that 
improve the document readability and clarity.


Yours,
Joel

On 2/6/19 5:17 PM, János Farkas wrote:

Hi Joel,

Thank you very much again for your review!

The draft had multiple updates since v08 you reviewed. The latest 
revision is v 11: 
https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0


The updates address review comments, and comments and discussions on the 
DetNet WG list.


Please let us know if you have further comments.

Regards,
Janos


On 10/19/2018 9:17 PM, Joel M. Halpern wrote:
Thank you Janos.  Two clarifications under retained text, with the 
rest elided.


Yours,
Joel

On 10/19/18 3:10 PM, János Farkas wrote:
...

On 9/22/2018 2:59 AM, Joel Halpern wrote:

...

Minor issues:
 Section 3.1 states that worst case delay for priority queueing is
 unbounded.  That does not match my understanding.  I know that 
DelayBound
 DSCP behavior tightly (although, I think, not as tightly as 
Detnet) limits

 both the worst case delay and the delay variation.
Strict priority is not good enough for DetNet. A high priority packet 
may need to wait until the transmission of a lower priority packet is 
finished at an outbound port, which can cause too much uncertainties 
in the network.


I understand that strict priority queueing is viewed as insufficient. 
I wasn;t arguing about that.  I was arguing with the use of the word 
"unbounded".  As far as I can tell, with suitable priority queueing 
the worst case delay is bounded, simply not well enough bounded.


...
 In section 4.1.2, I realized that the Detnet Transit node 
terminology had
 mildly confused me.  The text says "DetNet enabled nodes are 
interconnected
 via transit nodes (e.g., LSRs) which support DetNet, but are 
not DetNet
 service aware."  Reading this, and the definitions in section 
2.1, it
 appears that a Detnet Transit node is a node that is providing 
transport
 behavior that detnet needs, but is not actually modified for 
detnet.
Based on last call comments: 
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, 
the phrase "DetNet enabled nodes" is removed from the document and it 
has been made clear what type of DetNet node is meant:

The text is updated to:

    A "Deterministic Network" will be composed of DetNet enabled end
    systems, DetNet edge nodes, DetNet relay nodes and collectively
    deliver DetNet services.  DetNet relay and edge nodes are
    interconnected via DetNet transit nodes (e.g., LSRs) which support
    DetNet, but are not DetNet service aware.


Any chance you could simply say "transit nodes" instead of "DetNet 
transit nodes?  As far as I can tell, they are existing nodes that 
were designed and implemented (and even configured) potentially before 
DetNet was even defined?


...




___
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-detnet-architecture-08

[Joel M. Halpern]

Thanks Janos.  I will take a look at it promptly.
Yours,
Joel

On 2/6/19 5:17 PM, János Farkas wrote:

Hi Joel,

Thank you very much again for your review!

The draft had multiple updates since v08 you reviewed. The latest 
revision is v 11: 
https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0


The updates address review comments, and comments and discussions on the 
DetNet WG list.


Please let us know if you have further comments.

Regards,
Janos


On 10/19/2018 9:17 PM, Joel M. Halpern wrote:
Thank you Janos.  Two clarifications under retained text, with the 
rest elided.


Yours,
Joel

On 10/19/18 3:10 PM, János Farkas wrote:
...

On 9/22/2018 2:59 AM, Joel Halpern wrote:

...

Minor issues:
 Section 3.1 states that worst case delay for priority queueing is
 unbounded.  That does not match my understanding.  I know that 
DelayBound
 DSCP behavior tightly (although, I think, not as tightly as 
Detnet) limits

 both the worst case delay and the delay variation.
Strict priority is not good enough for DetNet. A high priority packet 
may need to wait until the transmission of a lower priority packet is 
finished at an outbound port, which can cause too much uncertainties 
in the network.


I understand that strict priority queueing is viewed as insufficient. 
I wasn;t arguing about that.  I was arguing with the use of the word 
"unbounded".  As far as I can tell, with suitable priority queueing 
the worst case delay is bounded, simply not well enough bounded.


...
 In section 4.1.2, I realized that the Detnet Transit node 
terminology had
 mildly confused me.  The text says "DetNet enabled nodes are 
interconnected
 via transit nodes (e.g., LSRs) which support DetNet, but are 
not DetNet
 service aware."  Reading this, and the definitions in section 
2.1, it
 appears that a Detnet Transit node is a node that is providing 
transport
 behavior that detnet needs, but is not actually modified for 
detnet.
Based on last call comments: 
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, 
the phrase "DetNet enabled nodes" is removed from the document and it 
has been made clear what type of DetNet node is meant:

The text is updated to:

    A "Deterministic Network" will be composed of DetNet enabled end
    systems, DetNet edge nodes, DetNet relay nodes and collectively
    deliver DetNet services.  DetNet relay and edge nodes are
    interconnected via DetNet transit nodes (e.g., LSRs) which support
    DetNet, but are not DetNet service aware.


Any chance you could simply say "transit nodes" instead of "DetNet 
transit nodes?  As far as I can tell, they are existing nodes that 
were designed and implemented (and even configured) potentially before 
DetNet was even defined?


...




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

Re: [Gen-art] [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

[Joel M. Halpern]

Good enough.
I suspect that any effort to refine further would be overkill, given 
that this is expected to be a rare case.
I think the small addition should be enough to alert any implementor or 
deployer to the challenges they might face.


Yours,
Joel

On 1/6/19 2:25 PM, Russ Housley wrote:

Joel:

I propose a replacement paragraph.  I hope it is more clear on the points 
raised on this thread:

The Root CA needs to ensure that the public key in the next
generation certificate is as strong or stronger than the key that it
is replacing.  Of course, a significant advance in cryptoanalytic
capability can break the yet-to-be-deployed key pair.  Such advances
are rare and difficult to predict.  If such an advance occurs, the
Root CA remains committed to the now broken key.  This leaves the
Root CA with no alternative but to deploy a new self-signed
certificate that contains a newly-generated key pair, most likely
using a different signature algorithm, in the same manner as the
initial self-signed certificate, thus losing the benefits of the Hash
Of Root Key certificate extension altogether.

Let me know if this helps...

Russ



On Jan 6, 2019, at 12:27 PM, Joel M. Halpern  wrote:

Maybe I am missing something simple, but I do not see where the text in section 5 on dealing with a 
lost promised key says anything about the need to "go through the process that was used to set 
up the initial trust anchor."  All it seems to say is "to deploy a new self-signed 
certificate."  Maybe what is needed is a little elaboration on what that deployment is to be, 
as it is not the same as deploying a properly promised new key pair.

Yours,
Joel

On 1/6/19 12:09 PM, Russ Housley wrote:

Joel:
As the text already says, the Root CA will need to go through the process that 
was used to set up the initial trust anchor.  The relying party will not accept 
the new self-signed certificate until that is done, and that process is 
completely disconnected from the previous certificate.
The paragraph we are discussing is all about handling a failure, and the new 
certificate extension is not offering any assistance if the failure occurs.  
That is what the paragraph is trying to say.
Russ

On Jan 4, 2019, at 10:10 PM, Joel M. Halpern  wrote:

I understand that the issuer has no choice.
What I can't see is how any validator will accept the new certificate.
The new cert will fail the validation check required by the field in the 
existing certificate.
So it seems that the only remedy is to wait until the exist certificate 
expires, so that the hash is no longer valid, and then a new cleann cert can be 
issued that will be accepted.

But there is no reference in the "remedy" to waiting for the expiration.
In fact, it is only imiplictly stated that the hash expectation is no longer 
valid once the certificate is expired.

Another possibility is that I am completely missing the point of the new field. 
 If the new clean unexpected cert will be accepted, what behavior is improved 
by having the hash in the current cert.

Yours,
Joel

On 1/4/19 9:41 PM, Russ Housley wrote:

Joel:
If access to the key is lost, the commitment is broken, so the Root CA must make a fresh 
start using a completely unrelated key.  Maybe the word "remedy" is creating 
the wrong impression for you.
Russ

On Jan 4, 2019, at 6:42 PM, jmh.dir...@joelhalpern.com 
<mailto:jmh.dir...@joelhalpern.com> wrote:

If the new self-signed cert uses a new key, wouldn't that be rejected as 
violating the promise in the current cert?  I am missing something.

Thanks,
Joel



Sent via the Samsung Galaxy S7, an AT 4G LTE smartphone

 Original message 
From: Russ Housley mailto:hous...@vigilsec.com>>
Date: 1/4/19 17:57 (GMT-05:00)
To: Joel Halpern mailto:j...@joelhalpern.com>>
Cc: IETF Gen-ART mailto:gen-art@ietf.org>>, sp...@ietf.org 
<mailto:sp...@ietf.org>, draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org 
<mailto:draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org>, IETF mailto:i...@ietf.org>>
Subject: Re: Genart last call review of   
draft-ietf-lamps-hash-of-root-key-cert-extn-03

Joel:

Thanks for the review.


Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03
Reviewer: Joel Halpern
Review Date: 2019-01-04
IETF LC End Date: 2019-01-10
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is nearly ready for publication as an Informational RFC.

Major issues: N/A

Minor issues:
The explanation at the end of section 5 about the remedy for losing access
to the new root key left me confused.
It looks like the situation is that there is a certificate out there, with the
hash of root key extensions. The certificate owner loses access to the new key
pair underlying the hash. The certificate owner clearly has to issue a new key
pair.  So far, so good.

What the text seems to say is to simply issue 

Re: [Gen-art] [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

[Joel M. Halpern]

Maybe I am missing something simple, but I do not see where the text in 
section 5 on dealing with a lost promised key says anything about the 
need to "go through the process that was used to set up the initial 
trust anchor."  All it seems to say is "to deploy a new self-signed 
certificate."  Maybe what is needed is a little elaboration on what that 
deployment is to be, as it is not the same as deploying a properly 
promised new key pair.


Yours,
Joel

On 1/6/19 12:09 PM, Russ Housley wrote:

Joel:

As the text already says, the Root CA will need to go through the process that 
was used to set up the initial trust anchor.  The relying party will not accept 
the new self-signed certificate until that is done, and that process is 
completely disconnected from the previous certificate.

The paragraph we are discussing is all about handling a failure, and the new 
certificate extension is not offering any assistance if the failure occurs.  
That is what the paragraph is trying to say.

Russ



On Jan 4, 2019, at 10:10 PM, Joel M. Halpern  wrote:

I understand that the issuer has no choice.
What I can't see is how any validator will accept the new certificate.
The new cert will fail the validation check required by the field in the 
existing certificate.
So it seems that the only remedy is to wait until the exist certificate 
expires, so that the hash is no longer valid, and then a new cleann cert can be 
issued that will be accepted.

But there is no reference in the "remedy" to waiting for the expiration.
In fact, it is only imiplictly stated that the hash expectation is no longer 
valid once the certificate is expired.

Another possibility is that I am completely missing the point of the new field. 
 If the new clean unexpected cert will be accepted, what behavior is improved 
by having the hash in the current cert.

Yours,
Joel

On 1/4/19 9:41 PM, Russ Housley wrote:

Joel:
If access to the key is lost, the commitment is broken, so the Root CA must make a fresh 
start using a completely unrelated key.  Maybe the word "remedy" is creating 
the wrong impression for you.
Russ

On Jan 4, 2019, at 6:42 PM, jmh.dir...@joelhalpern.com 
<mailto:jmh.dir...@joelhalpern.com> wrote:

If the new self-signed cert uses a new key, wouldn't that be rejected as 
violating the promise in the current cert?  I am missing something.

Thanks,
Joel



Sent via the Samsung Galaxy S7, an AT 4G LTE smartphone

 Original message 
From: Russ Housley mailto:hous...@vigilsec.com>>
Date: 1/4/19 17:57 (GMT-05:00)
To: Joel Halpern mailto:j...@joelhalpern.com>>
Cc: IETF Gen-ART mailto:gen-art@ietf.org>>, sp...@ietf.org 
<mailto:sp...@ietf.org>, draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org 
<mailto:draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org>, IETF mailto:i...@ietf.org>>
Subject: Re: Genart last call review of   
draft-ietf-lamps-hash-of-root-key-cert-extn-03

Joel:

Thanks for the review.


Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03
Reviewer: Joel Halpern
Review Date: 2019-01-04
IETF LC End Date: 2019-01-10
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is nearly ready for publication as an Informational RFC.

Major issues: N/A

Minor issues:
The explanation at the end of section 5 about the remedy for losing access
to the new root key left me confused.
It looks like the situation is that there is a certificate out there, with the
hash of root key extensions. The certificate owner loses access to the new key
pair underlying the hash. The certificate owner clearly has to issue a new key
pair.  So far, so good.

What the text seems to say is to simply issue a new self-signed certificate.
There are two possibilities for what is intended. I think the idea is that the
new certificate will use the existing key pair (not the promised one, nor
another new one) for its own signature, and include a new hash of root key for
the newly generated pair.  If the certificate owner can do that (I have not
dived into the rest of the certificate operations to figure out if that is
legal) then it works.  Please add some words explaining that better. If the
certificate owner can not simply issue a new self-signed certificate with the
existing key pair, then I am lost.  It appears that the text says that the
certificate owner issues a new self-signed certificate using a new key pair.
But that will fail the check against the previous certificate hash of root key.
I am hoping that it is the first of these alternatives, and all that is needed
is clearer explanatory text stating that the new cert uses the existing key
pair, and includes a new hash of root key promise.


Joel, the Root CA want to start using a different key par, but they have lost 
access to the one that was previously generated for that purpose.  So, the 
remedy is to create a new self-signed certificate with a newly gener

Re: [Gen-art] [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

[Joel M. Halpern]

I understand that the issuer has no choice.
What I can't see is how any validator will accept the new certificate.
The new cert will fail the validation check required by the field in the 
existing certificate.
So it seems that the only remedy is to wait until the exist certificate 
expires, so that the hash is no longer valid, and then a new cleann cert 
can be issued that will be accepted.


But there is no reference in the "remedy" to waiting for the expiration.
In fact, it is only imiplictly stated that the hash expectation is no 
longer valid once the certificate is expired.


Another possibility is that I am completely missing the point of the new 
field.  If the new clean unexpected cert will be accepted, what behavior 
is improved by having the hash in the current cert.


Yours,
Joel

On 1/4/19 9:41 PM, Russ Housley wrote:

Joel:

If access to the key is lost, the commitment is broken, so the Root CA 
must make a fresh start using a completely unrelated key.  Maybe the 
word "remedy" is creating the wrong impression for you.


Russ


On Jan 4, 2019, at 6:42 PM, jmh.dir...@joelhalpern.com 
 wrote:


If the new self-signed cert uses a new key, wouldn't that be rejected 
as violating the promise in the current cert?  I am missing something.


Thanks,
Joel



Sent via the Samsung Galaxy S7, an AT 4G LTE smartphone

 Original message 
From: Russ Housley mailto:hous...@vigilsec.com>>
Date: 1/4/19 17:57 (GMT-05:00)
To: Joel Halpern mailto:j...@joelhalpern.com>>
Cc: IETF Gen-ART mailto:gen-art@ietf.org>>, 
sp...@ietf.org , 
draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org 
, 
IETF mailto:i...@ietf.org>>
Subject: Re: Genart last call review of   
draft-ietf-lamps-hash-of-root-key-cert-extn-03


Joel:

Thanks for the review.

> Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03
> Reviewer: Joel Halpern
> Review Date: 2019-01-04
> IETF LC End Date: 2019-01-10
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This draft is nearly ready for publication as an 
Informational RFC.

>
> Major issues: N/A
>
> Minor issues:
>    The explanation at the end of section 5 about the remedy for 
losing access

>    to the new root key left me confused.
> It looks like the situation is that there is a certificate out 
there, with the
> hash of root key extensions. The certificate owner loses access to 
the new key
> pair underlying the hash. The certificate owner clearly has to issue 
a new key

> pair.  So far, so good.
>
> What the text seems to say is to simply issue a new self-signed 
certificate.
> There are two possibilities for what is intended. I think the idea 
is that the
> new certificate will use the existing key pair (not the promised 
one, nor
> another new one) for its own signature, and include a new hash of 
root key for
> the newly generated pair.  If the certificate owner can do that (I 
have not
> dived into the rest of the certificate operations to figure out if 
that is
> legal) then it works.  Please add some words explaining that better. 
If the
> certificate owner can not simply issue a new self-signed certificate 
with the
> existing key pair, then I am lost.  It appears that the text says 
that the
> certificate owner issues a new self-signed certificate using a new 
key pair.
> But that will fail the check against the previous certificate hash 
of root key.
> I am hoping that it is the first of these alternatives, and all that 
is needed
> is clearer explanatory text stating that the new cert uses the 
existing key

> pair, and includes a new hash of root key promise.

Joel, the Root CA want to start using a different key par, but they 
have lost access to the one that was previously generated for that 
purpose.  So, the remedy is to create a new self-signed certificate 
with a newly generated key.


Does that help?  If so, what would make the paragraph more clear?

Russ

___
Spasm mailing list
sp...@ietf.org 
https://www.ietf.org/mailman/listinfo/spasm




___
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

[Joel M. Halpern]

Dino, Med, please confirm if I am reading the thread properly:

I believe that the proposal is to make the small change below to 6833bis 
and to drop the "updates" reference from 8113bis to 6833bis.


I believe Dino's question was whether Brian agreed that the combination 
suggested would address his concern.


Yours,
Joel

On 12/20/18 2:55 PM, Brian E Carpenter wrote:

I may be missing something but I don't see how 8113bis can
logically cite 8113, which it replaces.

Frankly I think you've collectively created a plate of citation
spaghetti by not moving the IANA considerations for the type field
registry into 6830bis, which is where they naturally belong. If you
don't want to do that, I think you have to leave them in 8113bis and
simply lose the citation of 6833bis, which serves no purpose that
I can see.

Regards
Brian

On 2018-12-21 06:32, Dino Farinacci wrote:

I’ll make that change if Brian thinks it fixes the issues he raised.

Dino


On Dec 19, 2018, at 11:35 PM,  
 wrote:

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, 

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

[Joel M. Halpern]

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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 issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.






___
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp




___
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-lisp-rfc8113bis-01

[Joel M. Halpern]

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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 issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.








___
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-lisp-rfc8113bis-01

[Joel M. Halpern]

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.


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 issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.




___
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-httpbis-cdn-loop-01

[Joel M. Halpern]

Thanks for the rewrite on the first one.

I can live without adding the comment on the second.  I think the 
security folks will wonder and have to reproduce the reasoning as to why 
it is a non-issue.  (But if you add that disclaimer, they will probably 
just come up with another one.)


Yours,
Joel

On 12/17/18 10:26 PM, Mark Nottingham wrote:




On 18 Dec 2018, at 1:16 pm, Joel M. Halpern  wrote:

Thank you Mark.
On the first item, please look carefully at the use of pronouns.  It took me several 
readings to realize which CDNS "they" referred to.


I've rewritten to:

"""
Note that a CDN that allows customers to remove or modify the CDN-Loop header 
field (i.e., they do not implement this specification) remains an attack vector 
against both implementing and non-implementing CDNs.
"""


On the second item, it was not TLS protection I was referring to. Rather, I was 
imagining one bad cache stripping the loop prevention.  I think the real answer 
to that is that it is no worse than such a cache originating bad requests.


s/cache/intermediary/, but yes -- there isn't any (or at least significant) 
amplification.

Cheers,




Yours,
Joel

On 12/17/18 6:53 PM, Mark Nottingham wrote:

Hi Joel,
Thanks for the review.

On 4 Dec 2018, at 5:45 am, Joel Halpern  wrote:

...

This depends upon CDNs which have not been upgraded not stripping this
header.  While I can believe that is a reasonable assumption, it seems that
a paragraph explaining that it is the case, and if possible what experience
leads us to think it is the case, would be helpful.

I've added:
"""
Note that if a CDN that does not implement this specification allows customers 
to remove or modify the CDN-Loop header field, that CDN could become an attack 
vector against other CDNs, even if they do implement it.
"""

This document says that it is to protect against attackers causing loops.
If the attacker is an external customer, the advice in the security
considerations section makes sense.  The other apparent attack would be an
attacker in the network who strips the information each time it comes past.
 I believe the reason this is only an apparent attack is that such an
attacker could almost as easily simply generate additional messages instead
of producing a loop.  If I have inferred this correctly, it seems useful to
state it.

CDN back-end connections are increasingly protected by HTTPS. Also, most 
back-end connections are over transit that's unlikely to meddle in these ways 
(unless a state actor is involved).
Even so, the spec already says:
"""
The threat model that the CDN-Loop header field addresses is a customer who is 
attempting to attack
a service provider by configuring a forwarding loop by accident or malice.
"""
 which seems to address your concern. I'm wary of enumerating the attacks which this 
header doesn't prevent, since it's a necessarily open list. Inserting requirements like 
"back-end connections SHOULD be over HTTPS" are more appropriate for a general 
spec defining what a CDN is (and we're not there yet; this spec is a baby step towards 
that :).
Cheers,
--
Mark Nottingham   https://www.mnot.net/


--
Mark Nottingham   https://www.mnot.net/



___
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-httpbis-cdn-loop-01

[Joel M. Halpern]

Thank you Mark.
On the first item, please look carefully at the use of pronouns.  It 
took me several readings to realize which CDNS "they" referred to.


On the second item, it was not TLS protection I was referring to. 
Rather, I was imagining one bad cache stripping the loop prevention.  I 
think the real answer to that is that it is no worse than such a cache 
originating bad requests.


Yours,
Joel

On 12/17/18 6:53 PM, Mark Nottingham wrote:

Hi Joel,

Thanks for the review.


On 4 Dec 2018, at 5:45 am, Joel Halpern  wrote:

...

This depends upon CDNs which have not been upgraded not stripping this
header.  While I can believe that is a reasonable assumption, it seems that
a paragraph explaining that it is the case, and if possible what experience
leads us to think it is the case, would be helpful.


I've added:

"""
Note that if a CDN that does not implement this specification allows customers 
to remove or modify the CDN-Loop header field, that CDN could become an attack 
vector against other CDNs, even if they do implement it.
"""


This document says that it is to protect against attackers causing loops.
If the attacker is an external customer, the advice in the security
considerations section makes sense.  The other apparent attack would be an
attacker in the network who strips the information each time it comes past.
 I believe the reason this is only an apparent attack is that such an
attacker could almost as easily simply generate additional messages instead
of producing a loop.  If I have inferred this correctly, it seems useful to
state it.


CDN back-end connections are increasingly protected by HTTPS. Also, most 
back-end connections are over transit that's unlikely to meddle in these ways 
(unless a state actor is involved).

Even so, the spec already says:

"""
The threat model that the CDN-Loop header field addresses is a customer who is 
attempting to attack
a service provider by configuring a forwarding loop by accident or malice.
"""

 which seems to address your concern. I'm wary of enumerating the attacks which this 
header doesn't prevent, since it's a necessarily open list. Inserting requirements like 
"back-end connections SHOULD be over HTTPS" are more appropriate for a general 
spec defining what a CDN is (and we're not there yet; this spec is a baby step towards 
that :).

Cheers,


--
Mark Nottingham   https://www.mnot.net/



___
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-detnet-architecture-08

[Joel M. Halpern]

Thank you Janos.  Two clarifications under retained text, with the rest 
elided.


Yours,
Joel

On 10/19/18 3:10 PM, János Farkas wrote:
...

On 9/22/2018 2:59 AM, Joel Halpern wrote:

...

Minor issues:
 Section 3.1 states that worst case delay for priority queueing is
 unbounded.  That does not match my understanding.  I know that DelayBound
 DSCP behavior tightly (although, I think, not as tightly  as Detnet) limits
 both the worst case delay and the delay variation.
Strict priority is not good enough for DetNet. A high priority packet 
may need to wait until the transmission of a lower priority packet is 
finished at an outbound port, which can cause too much uncertainties in 
the network.


I understand that strict priority queueing is viewed as insufficient.  I 
wasn;t arguing about that.  I was arguing with the use of the word 
"unbounded".  As far as I can tell, with suitable priority queueing the 
worst case delay is bounded, simply not well enough bounded.


...

 In section 4.1.2, I realized that the Detnet Transit node terminology had
 mildly confused me.  The text says "DetNet enabled nodes are interconnected
 via transit nodes (e.g., LSRs) which support DetNet, but are not DetNet
 service aware."  Reading this, and the definitions in section 2.1, it
 appears that a Detnet Transit node is a node that is providing transport
 behavior that detnet needs, but is not actually modified for detnet.
Based on last call comments: 
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, the 
phrase "DetNet enabled nodes" is removed from the document and it has 
been made clear what type of DetNet node is meant:

The text is updated to:

A "Deterministic Network" will be composed of DetNet enabled end
systems, DetNet edge nodes, DetNet relay nodes and collectively
deliver DetNet services.  DetNet relay and edge nodes are
interconnected via DetNet transit nodes (e.g., LSRs) which support
DetNet, but are not DetNet service aware.


Any chance you could simply say "transit nodes" instead of "DetNet 
transit nodes?  As far as I can tell, they are existing nodes that were 
designed and implemented (and even configured) potentially before DetNet 
was even defined?


...

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

Re: [Gen-art] [netmod] Genart telechat review of draft-ietf-netmod-schema-mount-11

[Joel M. Halpern]

I had thought we had discussed sufficient edits.  When I looked at the 
diff, what I saw helped some, but still left me concerned.

Yours,
Joel

On 10/4/18 6:06 AM, Martin Bjorklund wrote:

Hi,

Joel Halpern  wrote:

Reviewer: Joel Halpern
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 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-netmod-schema-mount-??
Reviewer: Joel Halpern
Review Date: 2018-10-03
IETF LC End Date: 2018-06-29
IESG Telechat date: 2018-10-11

Summary: This document seems to meet the specific requirements for publication
as a proposed standard.

Major issues:
 It is still this reviewer's opinion that for a reader who has not been
 involved in the discussion in the working group, the document is quite
 unclear and confusing.   For somewhat more details, please see my previous
 review at
 
https://datatracker.ietf.org/doc/review-ietf-netmod-schema-mount-10-genart-lc-halpern-2018-06-28/


I'm sorry to hear that you find it confusing.  I was under the
impression that the edits that we made after your previous review were
sufficient.


/martin





Minor issues:
 N/A

Nits/editorial comments:
 N/A


___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



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

Re: [Gen-art] [Anima] Genart last call review of draft-ietf-anima-reference-model-06

[Joel M. Halpern]

Thank you Michael.
Seems that we are good.
Yours,
Joel

On 8/17/18 10:36 AM, Michael Richardson wrote:

Joel Halpern  wrote:
 > Does section 3.3.2 intend to mandate that devices have persistent
 > storage for the LDevID?  Or is it trying to say that on power cycle it
 > stays in Enrolled state if it retains its LDevID, but goes back to the
 > Factory default state if not?  (Given that folks have repeatedly said
 > that these may be low power devices, I think we need to be clear about
 > what we are requiring.)

*) Constrained devices are not, in general, in scope for the WG
*) Regardless, the LDevID needs to be persisted, and I agree we should say that.

 > Section 5 starts by saying that the administrator does not have to
 > configure security.  In the very next paragraph it says that a PKI must
 > be in place.  That clearly requires configuring some security
 > properties.  Please reword.

The administrator has to have a PKI.  We considered making the PKI
auto-configuring, but we backed out of that as a hard requirement.
I agree that this text need to be clarified.

 > Section 3.3.2 in defining when a device is in the Enrolled state
 > says that it in the Enrolled state if it has an LDevID.  As far as I
 > can tell, the added constraint is that it is not currently a member of
 > an ACP.  The text should include that.

Agreed.

 > The third paragraph of section 6.1 refers to the Autonomic nodes
 > and the ASAs as "self-aware".  I do not know what meaning is being
 > ascribed to that phrase.  The usage does not seem to correspond to any
 > meaning I can understood.  Can we just remove the sentence?  (I suspect
 > that the intention is to lead to the fact that the functions can
 > advertise their capabilities, and negotiate them.  We don't need the
 > sentence as grounding for that.)

I think that the intent is to say that the ASA will have a model of itself.
I think that it would be better to say that.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



--
Michael Richardson , Sandelman Software Works
  -= IPv6 IoT consulting =-





___
Anima mailing list
an...@ietf.org
https://www.ietf.org/mailman/listinfo/anima



___
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-anima-reference-model-06

[Joel M. Halpern]

At this point I think we understand each other's points, and I will wait 
for Michael to comment as pen-holder.

Thank you for the prompt response and discussion.
Yours,
Joel

PS: While I sympathize with your reaction to paying for standards from 
other SDOs, that is not what determines whether we reference them, or 
whether those references are normative.  No mater how much we wish 
otherwise :-)



On 8/10/18 12:12 PM, Toerless Eckert wrote:

On Fri, Aug 10, 2018 at 10:12:37AM -0400, Joel M. Halpern wrote:

Imho, the reference model text is correct. Just like in the non-autonomic
input (third bullet item), this vendor-redirect/cloud-registrar would
lead to an automatically set up remote ACP peer thats enterred into the
adjacency table.

I can't find anything in the bootstrap document redirect section that
suggests the behavior you indicate.


Thats true, the BRSKI documents defines key cryptographic aspects
of a cloud registrar and there are a lot of options for a full solution,
and the conclusion was to do these things as followup work from BRSKI / ACP.


Hmm.. ACP is an overlay network that tries to match the underlay when
it can (link-local-adjacencies) and that uses remote adjacencies when
it needs to go over non-autonomic parts of the network.

Not quite sure what text to most easily add to make this any clearer..
Any suggestions ?

The text mixes both uses of adjacency without distinction.  One could
seaprate the usage.  One could add explanatory text.  Something to clarify
the situation. 


Hmm.. it does clearly distinguish the three cases through bullet
points, each one describing one of the three cases. Maybe i'm
just confused what you think is missing and Michael immediately sees it.


802.1AR as already referenced by ACP

My only concern is that it appears to need to be a normative reference
here, as it seems to be needed for understanding this document. 


I don't think its necessary to read 802.1AR to understand
the security reason why its used. BRSKI does that explanation,
and BRSKI is already normative. Personally, i dislike to have "pay-to-read"
documents as normative references, as much as i do appreciate
every SDOs need to finance itself.


The security model of nodes without writable persistent storage comes
to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash
only, power-cycle recreates known "good" state on device).


The text as written implicitly requires persistent storage.  If the
intention is to allow both models (as I would hope) please tune the text in
section 3.3.2.


Maybe a sentence at the end:

On devices without persistent storage for the LDevID, a powercycle
should behave like a factory reset.


chair hat on:
There can not be a draft covering this yet, because the current
ANIMA charter didn't allow us to do this. We've got individual drafts
lined up for this topic, we just need to get through the rechartering,
we have started the discuss with our AD and wanted to then bring this to
the WG.

How can this informational documents say "ASA must ..." if there is no
definition of what they must do.  If the WG has not addressed this topic,
then reword this.  Maybe "It is expected that wide deployment in the future
will need ..." 


I think 6.1 is just missing the (*).

Cheers
Toerless



___
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-anima-reference-model-06

[Joel M. Halpern]

I await Michael's comments.  A few in line responses (marked  
where I think I may have been misunderstood.  I have trimmed the rest. 
As noted in the elided text, these are all concerned with clarity.


Yours,
Joel

On 8/10/18 1:10 AM, Toerless Eckert wrote:


On Thu, Aug 09, 2018 at 06:00:39PM -0700, Joel Halpern wrote:

Reviewer: Joel Halpern
Review result: Ready with Issues




Minor issues:
 Section 2 includes "naming" in the list of services the ANI provides.
 Which surprised me.  But then section 3 does not include "naming" in the
 list of services of the ANI in Figure 2 of section 3.1?


4.1 is explaining it. In the ACP document its called the Node-ID.


I saw 4.1.  If naming is intended to be a service provided by the 
ACP, then figure 2 and the text in section 3.1 apparently should include 
it. 





 In section 3.2, in the second paragraph on where adjacency information
 comes from, the text of the second bullet refers to vendor redirects.
 While I understand that those are an important part of the system
 information, they do not appear to create an adjacency?  If they do, then
 the term adjacency needs to be better explained in this section.  The first


Imho, the reference model text is correct. Just like in the non-autonomic
input (third bullet item), this vendor-redirect/cloud-registrar would
lead to an automatically set up remote ACP peer thats enterred into the
adjacency table.
I can't find anything in the bootstrap document redirect section 
that suggests the behavior you indicate.





 bullet in the next list says the same thing.  My best guess is that
 adjacency sometime means actual topological adjacency, and sometimes means
 a more general form of adjacency.  As written, I think it will confuse
 readers.


Hmm.. ACP is an overlay network that tries to match the underlay when
it can (link-local-adjacencies) and that uses remote adjacencies when
it needs to go over non-autonomic parts of the network.

Not quite sure what text to most easily add to make this any clearer..
Any suggestions ?
The text mixes both uses of adjacency without distinction.  One 
could seaprate the usage.  One could add explanatory text.  Something to 
clarify the situation. 





 IDevID (referenced in section 3.3.1 at least) appears to be a normative
 reference.  Devices supporting the Anima Reference Model are required to
 support that, so understanding how to do so seems necessary for
 understanding this specification.


802.1AR as already referenced by ACP
My only concern is that it appears to need to be a normative 
reference here, as it seems to be needed for understanding this 
document. 





 Does section 3.3.2 intend to mandate that devices have persistent storage
 for the LDevID?  Or is it trying to say that on power cycle it stays in
 Enrolled state if it retains its LDevID, but goes back to the Factory
 default state if not?  (Given that folks have repeatedly said that these
 may be low power devices, I think we need to be clear about what we are
 requiring.)


Both options are architecturally valid and the reference model
does not take sides, even though we would expect that LDevID is
persistent in most cases.

I don't think low-power is the criteria for not to have a persistent LDevID,
almost every tiny IoT device i've seen has some available flash cells.

The security model of nodes without writable persistent storage comes
to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash
only, power-cycle recreates known "good" state on device).


The text as written implicitly requires persistent storage.  If the 
intention is to allow both models (as I would hope) please tune the text 
in section 3.3.2.





 Section 5 starts by saying that the administrator does not have to
 configure security.  In the very next paragraph it says that a PKI must be
 in place.  That clearly requires configuring some security properties.
 Please reword.


I had same comment on ACP. I was going to fix it in ACP by saying
"does not need to configure security on any (ANI/ACP) nodes other
than Registrars and other PKI components (CA, CRL-DP,...).

Network can have 10,000 nodes and maybe just 2 registrar/CAs..


 Section 6.2 says that all ASA must "follow the same operating principles".
 The general guideliens of what these must cover is then given.  It is
 appropriate that this document does not specify the detailed behavior.
 That would go in a standards track document.  But there is no reference to
 a draft covering that.  So we have text saying that all ASA must follow
 "something", but no reference as to the content of that "something".  Is
 this a real requirement?  If so, it appears to be unmeetable.


chair hat on:
There can not be a draft covering this yet, because the current
ANIMA charter didn't allow us to do this. We've got individual drafts
lined up for this 

Re: [Gen-art] [core] Genart last call review of draft-ietf-core-object-security-13

[Joel M. Halpern]

Thank you.  Those changes nicely address my concerns.
Yours,
Joel

On 7/26/18 2:41 AM, Francesca Palombini wrote:

Hi Joel,

Thanks for your review! I now have updated the draft with improvements from 
your comments, see inline. Hope this clarifies.

Thanks,
Francesca


-Original Message-
From: core  On Behalf Of Joel Halpern
Sent: den 20 juli 2018 04:08
To: gen-art@ietf.org
Cc: draft-ietf-core-object-security@ietf.org; i...@ietf.org; c...@ietf.org
Subject: [core] Genart last call review of draft-ietf-core-object-security-13

Reviewer: Joel Halpern
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-core-object-security-13
Reviewer: Joel Halpern
Review Date: 2018-07-19
IETF LC End Date: 2018-07-30
IESG Telechat date: Not scheduled for a telechat

Summary: this document is ready for publication as a Proposed Standard
RFC.
 My minor concerns from draft -08 have been addressed.

Major issues: N/A

Minor issues:
 Section 7.2 is about sequence numbers.  The first sentence in 7.2 discusses
 Nonces.  Then the discussion switches to sequence numbers?  My guess is
 that the Nonce is left over from previous text?



Actually, the first sentence discusses nonces since they are constructed from 
Partial IVs, which are basically the Sequence Numbers. I added this precision, 
at the end of the second sentence.

OLD:  An AEAD nonce MUST NOT be used more than once per AEAD key. The 
uniqueness of (key, nonce) pairs is shown in Appendix D.3, and in particular 
depends on a correct usage of Partial IVs.

NEW: An AEAD nonce MUST NOT be used more than once per AEAD key. The uniqueness 
of (key, nonce) pairs is shown in Appendix D.3, and in particular depends on a 
correct usage of Partial IVs (which encode the Sender Sequence Numbers, see 
Section 5).


Nits/editorial comments:
 In the first paragraph of 3.3, the text reads:
   The requirement that Sender ID SHALL be unique in the set of all security
   contexts using the same Master Secret, Master Salt, and ID Context
   guarantees unique (key, nonce) pairs, which avoids nonce reuse.
 Unfortunately, that is not a grammatical sentence.




I think this sentence was too long to be readable, so I tried to split it up. 
Hopefully it makes more sense now.

NEW: This means that Sender ID SHALL be unique in the set of all security 
contexts using the same Master Secret, Master Salt, and ID Context; such a 
requirement guarantees unique (key, nonce) pairs, which avoids nonce reuse.


___
core mailing list
c...@ietf.org
https://www.ietf.org/mailman/listinfo/core


___
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-dnsop-session-signal-11

[Joel M. Halpern]

Thank you Ted.  Those address my concerns.
Yours,
Joel

On 7/9/18 9:07 PM, Ted Lemon wrote:
I got a bit wound up about not making the three changes that Joel called 
out in the updated session signal comment, and insisted on not making 
the changes because they didn't seem that important.   I had a bit more 
private conversation with Joel about it, and after some reflection 
decided that it might be worth suggesting some changes after all based 
on Joel's comments.


What I would propose to fix these three issues are the following three 
changes.


In 5.1.3:

OLD:

Where an application-layer middlebox (e.g., a DNS proxy, forwarder,
or session multiplexer) is in the path, the middlebox MUST NOT
blindly forward DSO messages in either direction, and MUST treat the
inbound and outbound connections as separate sessions.  This does not
preclude the use of DSO messages in the presence of an IP-layer
middlebox, such as a NAT that rewrites IP-layer and/or transport-
layer headers but otherwise preserves the effect of a single session
between the client and the server.

NEW:

Where an application-layer middlebox (e.g., a DNS proxy, forwarder,
or session multiplexer) is in the path, care must be taken to avoid

inappropriately passing session signaling through the middlebox.


In cases where a DSO session is terminated on one side of a middlebox,

and then some session is opened on the other side of the middlebox in

order to satisfy requests sent over the first DSO session, any such session

MUST be treated as a separate session.


This does not

preclude the use of DSO messages in the presence of an IP-layer
middlebox, such as a NAT that rewrites IP-layer and/or transport-
layer headers but otherwise preserves the effect of a single session
between the client and the server.  And of course it does not apply

to middleboxes that do not implement DNS Stateless Operations.


These restrictions do not apply to middleboxes that do not implement

DSO: since they have no way to understand a DSO message, a pass-through

middlebox like the one described in the previous paragraph will pass

DSO messages unchanged or drop them (or possibly drop the connection).

A middlebox that is not doing a strict pass-through will have no way

to know on which connection to forward a DSO message, and therefore

will not be able to behave incorrectly.


In 5.2.2:
OLD:

A DSO response message may contain no TLVs, or it may be specified to
contain one or more TLVs appropriate to the information being
communicated.  This includes "Primary TLVs" and "Additional TLVs"
defined in this document as well as in future TLV definitions.


NEW:

A DSO response message may contain no TLVs, or it may be specified to
contain one or more TLVs appropriate to the information being
communicated.  This includes "Primary TLVs" and "Additional TLVs"
defined in this document as well as in future TLV definitions.

It may be permissible for an additional TLV to appear in a response

to a primary TLV even though the specification of that primary TLV

does not specify it explicitly.   See section 8.2 for more information.


In 5.4:
OLD:

With most TCP implementations, for DSO requests that generate a
response, the TCP data acknowledgement (generated because data has
been received by TCP), the TCP window update (generated because TCP
has delivered that data to the receiving software), and the DSO
response (generated by the receiving application-layer software
itself) are all combined into a single IP packet.  Combining these
three elements into a single IP packet can give a significant
improvement in network efficiency.


NEW:
With most TCP implementations, for DSO requests that generate a

response, the TCP data acknowledgement (generated because data has
been received by TCP), the TCP window update (generated because TCP
has delivered that data to the receiving software), and the DSO
response (generated by the receiving application-layer software
itself) are all combined into a single IP packet.  Combining these
three elements into a single IP packet can give a significant
improvement in network efficiency, assuming that the DSO response

is sent before the TCP Delayed Acknowledgement timer goes off.




___
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-dnsop-session-signal-11

[Joel M. Halpern]

I will try to elaborate on the problems below.
Joel

On 7/5/18 6:28 PM, Ted Lemon wrote:
The text also says that it's fine to blindly forward DSO messages if the 
middlebox isn't modifying the stream, e.g. in a NAT.   It really is 
quite clear on that point.   The case where it's bad to blindly forward 
DSO messages is when there is no stream that's the same stream on both 
sides of the middlebox.   In this case, it really is a MUST NOT.   What 
reader's need are you trying to address here?   Who is going to be 
reading the document and is going to be confused about this?


The text in 5.3.1 says that middleboxes MUST NOT do blind forwarding. 
Regarding the further text, given the wroding it is actually very hard 
to understand whether that is supposed to be an exception to the MUST 
NOT, or a description of some other case.
Even if the further text covers a lot of cases, the MUST NOT is 
presumably describing a situation that existing middleboxes do find 
themselves in.  I do think it is fair to ask for an explanation of why 
existing middleboxes that do fall into the relevant case will do the 
right thing.  Are there no such existing middleboxes (seems unlikely)? 
Do such existing middleboxes already for some reason do things that will 
prevent the blind forwarding (that would be great, just explain it)?  Or 
is it actually okay that existing middleboxes violate the MUST NOT (in 
which case, why is it a MUST NOT)?




As far as I can tell, the text on Nagle is correct, and you haven't 
pointed to an error.  You appear to have said that you want it to place 
a new requirement on the sender to respond within the 200ms DA window.   
This is unnecessary.   What am I missing?


What the text in 5.4 actually says is that magically the data will be 
piggybacked.   It treats it as if there are only two cases, DSO requests 
that generate a response that automatically combine the two, and DSO 
requests that do not generate responses.  The reality is that there are 
three cases.
1) DSO requests that get responses and are responded fast enough to get 
nagle behavior and the resulting performance benefit,
2) DSO requests that get responses and for whatever reason are responded 
to more slowly

3) DSO requests that do not generate responses.

The fix, it seems to me is to make two small changes:
A) In the first sentence of 5.4, change "for DSO requests that generate 
a response" to "for DSO requests that generate a response and are 
responded to in a sufficiently timely fashion"
B) At the start of the second paragraph, change "For DSO requests that 
do not generate a response" to "For DSO requests that do not generate a 
response or those that generate a response but are not responded to in a 
sufficiently timely fashion"


This has the side benefit of making clear to implementors that ensuring 
responsiveness of their implementation will improve the network utilization.


___
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-dnsop-session-signal-11

[Joel M. Halpern]

In line.  The general point is that the document should be clear to 
readers who understand the space but do not live it at the detail of 
those who authored it.


Joel

On 7/5/18 6:13 PM, Ted Lemon wrote:
Joel, it's immaterial whether the DSO engine responds in time or not.   
If it responds in time, the ack and the response will be combined; if it 
does not, then Nagle's algorithm will ensure that the ack goes out, and 
the response will go out in a later packet.   Either outcome is fine.   
There is no need to caution the implementor that they should ensure a 
quick response—if they don't care to get the response out in 200ms, they 
obviously don't care about performance, and that's perfectly fine.   It 
is absolutely /not/ a requirement that they do so.   The point of this 
text in the document is to inform implementors that /do/ care about 
performance about the interaction between Nagle and DA.


The text says that combining will happen.  I am well aware that if the 
processing is in time, that is normal processing.  But that is not what 
the text says.  It would take about a sentence to fix the text to match 
what you describe above.




We looked at your comment about middleboxes and couldn't figure out what 
problem you are trying to solve here.   If a middlebox is not DSO-aware, 
it's going to prevent DSO from working (which would be correct), or else 
forward it unchanged (which would also be correct).   The text is an 
admonishment for implementations that are DSO-aware.   If an 
implementation is not DSO-aware, then adding text to instruct the 
implementor, who presumably will not read it, doesn't make sense.


The text says that middleboxes MUST NOT blindly forward DSO messages. 
Your text above says that actually it doesn't matter, and no, existing 
middleboxes will not comply with this MUST NOT.  A MUST NOT in a 
document is generally a statement that things will break if they behave 
wrong.  Thus, what the document says, combined with your behavioral 
description, is that existing middleboxes will break DSO.  I doubt that 
(which is why I consider this minor rather than major.)  Please fix the 
text to either not require changes to existing middleboxes or to explain 
to readers why and how existing middlebox will comply with the MUST NOT.





Your proposed change to 5.2.2 seems fine to me—I don't remember what 
happened with that.


On Thu, Jul 5, 2018 at 5:48 PM, Joel Halpern > wrote:


Reviewer: Joel Halpern
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-dnsop-session-signal-11
Reviewer: Joel Halpern
Review Date: 2018-07-05
IETF LC End Date: 2018-06-25
IESG Telechat date: 2018-08-02

Summary: This document is ready for publication as a Proposed
Standard RFC

Some of my earlier comments have been addressed.  It appears that an
effort was
made to address more, but I was apparently unclear.  I have copied
the comments
that seem to still apply, with elaboration.  If I am still unclear,
please
contact me.

Major issues: N/A

Minor issues:
     Section 5.1.3 places some requirements on application level
middleboxes,
     and includes a very clear explanation of why it places these
requirements.
     While it may be "obvious" to one who lives and breathes DNS, I
think it
     would help to explain why the usual operation of an existing
middlebox will
     (typically? always?  inherently?) meet this requirement.  To
rephrase, the
     text says things like "the middlebox MUST NOT blindly forward
DSO messages
     in either direction." Apparently, somehow, the existing world
middleboxes
     will do comply with this.  How?

     The third and fourth paragraphs of section 5.2.2 do not talk
about optional
     additional TLVs.  It would be helpful if the document stated
that in
     addition to those additional TLVs required by the primary TLV,
other TLVs
     may be included based on their individual definition,
independent of the
     definition of the primary TLV.  (Both the Encryption padding
and the delay
     retry TLVs may be included in suitable messages without being
called out in
     the definition of the primary TLVs.)
     An effort appears to have been made to address this, which
suggests I was
     unclear.  The text says:
         A DSO response message may contain no TLVs, or it may be
specified to
         

Re: [Gen-art] Genart last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

[Joel M. Halpern]

You have made the changes you have said you would make.
I do not think the document is as clear as it should be about the 
assumptions that make this workable (for example that it can not handle 
SR LSP that are not intended to have reserved bandwidth).

I will leave it to the judgment of others whether this is a show stopper.

Yours,
Joel

On 4/26/18 11:01 AM, Harish Sitaraman wrote:


Hi Joel,

We've posted a -03 version of the draft. Let us know if it helps with the comments. 
See inline ...

On 4/20/18, 11:25 AM, "Joel M. Halpern" <j...@joelhalpern.com> wrote:

 Thank you for your replies.  Further in line, marked 
 Yours,
 Joel
 
 On 4/20/18 1:36 PM, Harish Sitaraman wrote:

 >
 > Hi Joel,
 >
 > Thanks for the review comments. Comments are inline with [HS].
 >
 > On 4/19/18, 3:15 AM, "Joel Halpern" <j...@joelhalpern.com> wrote:
 >
 >  Summary:
 >
 >  Major issues:
 >  The focus of the draft seems to be the recommendation in 
section 3.5 that
 >  the maximum reservable bandwidth on a link be adjusted to 
reflect the SR
 >  traffic consumption.  There appear to be two issues that need 
to be
 >  discussed, both related to the difference between what the SR 
controller
 >  wants to reserve and what the router observes. First, an SR 
controller may
 >  be performing calculations without requiring that bandwidth be 
committed to
 >  the traffic.  The recommendation here assumes that all traffic 
using SR is
 >  high priority.  It may suffice to note that QoS markings in the 
labels
 >  (corresponding to diffserv markings in the underlying packet 
may hel with
 >  this.  Given the range of allowed behaviors in when RSVP-TE and 
SR are
 >  separate, it may also be necessary to restrict what the SR 
controllers do
 >  in these interworking cases.
 >
 > [HS] In the first paragraph of section 3.5, there is text referring to 
SR having highest preemption priority but the SR traffic could have different QoS 
markings i.e. within SR there could be different classes of traffic which is 
accordingly handled by the forwarding plane (e.g. defined operator policy).
 
 I think the document would be helped if this were described more

 explicitly.  

 The first paragraph in section 3.5 explains the preemption priority and 
forwarding plane priority as follows:

The solution relies on dynamically measuring SR traffic utilization
on each TE interface and reducing the bandwidth allowed for use by
RSVP-TE.  It is assumed that SR traffic receives precedence in terms
of the placement on the path over RSVP traffic (that is, RSVP traffic
can be preempted from the path in case of insufficient resources).
This is logically equivalent to SR traffic having the best preemption
priority in the network.  Note that this does not necessarily mean
that SR traffic has higher QoS priority, in fact, SR and RSVP traffic
may be in the same QoS class.
 
 >

 >  Second, and more importantly, this solution
 >  assumes that short term traffic measurements are a good proxy 
for intended
 >  reservation.  Even assuming edge policing so that usage is less 
than or
 >  equal to the reservation, this will frequently underestimate 
the traffic
 >  reservation.  Such underestimates would seem to be able to cause
 >  significant problems.
 >
 > [HS] Even with RSVP-TE LSPs where explicit admission-control is done to 
reserve bandwidth, the bandwidth that is reserved on the RSVP-TE LSP may differ 
from how much traffic actually arrives on the LSP (assuming no edge policing). As 
the traffic changes, auto-bandwidth implementation procedures might be there to 
adjust the LSP reservation at periodic intervals. This relies on short term LSP 
traffic measurement to achieve change in reservation.
 
 A reference or two to other work on auto-reservation of bandwidth

 based on measurement, particularly for RSVP-TE, would help the reader
 understand the assumptions that lead to this being seen as workable.  It
 would likely also help the reader know about any relevant 
limitations.
 
 Regarding the IETF reference for auto-bandwidth, I could only find the following PCE WG document: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-auto-bandwidth-06#page-8 (section 4) other than public references to vendor implementation documentation.


 >
 > [HS] SR traffic can preempt RSVP LSPs to make room for itself based on 
short term SR traffic measurement. The frequency at which SR statistics is 
collected for a TE interface and how often the Maxim

Re: [Gen-art] Genart last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

[Joel M. Halpern]

Thank you for your replies.  Further in line, marked 
Yours,
Joel

On 4/20/18 1:36 PM, Harish Sitaraman wrote:


Hi Joel,

Thanks for the review comments. Comments are inline with [HS].

On 4/19/18, 3:15 AM, "Joel Halpern"  wrote:

 Summary:
 
 Major issues:

 The focus of the draft seems to be the recommendation in section 3.5 
that
 the maximum reservable bandwidth on a link be adjusted to reflect the 
SR
 traffic consumption.  There appear to be two issues that need to be
 discussed, both related to the difference between what the SR 
controller
 wants to reserve and what the router observes. First, an SR controller 
may
 be performing calculations without requiring that bandwidth be 
committed to
 the traffic.  The recommendation here assumes that all traffic using 
SR is
 high priority.  It may suffice to note that QoS markings in the labels
 (corresponding to diffserv markings in the underlying packet may hel 
with
 this.  Given the range of allowed behaviors in when RSVP-TE and SR are
 separate, it may also be necessary to restrict what the SR controllers 
do
 in these interworking cases.

[HS] In the first paragraph of section 3.5, there is text referring to SR 
having highest preemption priority but the SR traffic could have different QoS 
markings i.e. within SR there could be different classes of traffic which is 
accordingly handled by the forwarding plane (e.g. defined operator policy).


I think the document would be helped if this were described more 
explicitly.  




 Second, and more importantly, this solution
 assumes that short term traffic measurements are a good proxy for 
intended
 reservation.  Even assuming edge policing so that usage is less than or
 equal to the reservation, this will frequently underestimate the 
traffic
 reservation.  Such underestimates would seem to be able to cause
 significant problems.

[HS] Even with RSVP-TE LSPs where explicit admission-control is done to reserve 
bandwidth, the bandwidth that is reserved on the RSVP-TE LSP may differ from 
how much traffic actually arrives on the LSP (assuming no edge policing). As 
the traffic changes, auto-bandwidth implementation procedures might be there to 
adjust the LSP reservation at periodic intervals. This relies on short term LSP 
traffic measurement to achieve change in reservation.


A reference or two to other work on auto-reservation of bandwidth 
based on measurement, particularly for RSVP-TE, would help the reader 
understand the assumptions that lead to this being seen as workable.  It 
would likely also help the reader know about any relevant limitations.




[HS] SR traffic can preempt RSVP LSPs to make room for itself based on short 
term SR traffic measurement. The frequency at which SR statistics is collected 
for a TE interface and how often the Maximum-Reservable-Bandwidth is adjusted 
so that path computation engines for RSVP-TE LSPs get the updated TED 
information is implementation and deployment dependent (it could be aggressive 
to reflect SR traffic utilization in the TED often or done less frequently due 
to other deployment parameters). In the penultimate paragraph of section 3.5, 
there is text referring to the implementation choice.


The point of reservations is to try to anticipate future 
conditions.  The fact that SR can preempt RSVP-TE is useful, but does 
not really address the question.  If it could, then a simpler 
recommendation would be to observe how much RSVP-TE trafic had to be 
dropped, and redirect that much traffic elsewhere. 


 
 Minor issues:

 Section 3.5 assumes that the router can measure the traffic using SR.  
This
 seems to rely on the unstated premise that the measurement is 
conditioned
 by the recognition of which labels are being used for SR.  This is
 reasonable.  It should be stated.

[HS] Fair point. However, the measured traffic is not just from SR labels 
(transit traffic) but also any traffic entering the SR domain over that 
outgoing interface. An implementation should be capable of measuring all the SR 
traffic going out of an interface. The text generically refers to needing 
ability to measure SR traffic statistics across the TE interface.


My point is that it would help the reader if the text were explicit 
about what traffic needs to be recognized and how it is recognized. 


 
 Nits/editorial comments:

 The second paragraph of the introduction seems to have the opening text
 repeated twice.

[HS] Thanks - noted also as part of OPsDir review comments. The 2nd repeated 
sentence will be removed.
 
 The third paragraph of section 3.1 seems to be a repetition of the end of

 the second paragraph using slightly different words.

[HS] Ok, the aim was to offer a summary of the behavior 

Re: [Gen-art] [RTG-DIR] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

Thank you Jimmy.
While I disagree, I think this states the case clearly enough for it to 
be up to the working group and relevant ADs.


Yours,
Joel

On 4/15/18 11:40 PM, Dongjie (Jimmy) wrote:

Hi Joel,

Thanks a lot for your review comments.

Regarding your first problem, I don't think this draft introduces "significant new 
processing load on the router", as similar processing has already been done for the 
BGP AS number and BGP-nexthop based traffic collection. As described in the draft, the 
BGP-community based traffic collection is done by BGP lookup and correlating the BGP 
community with the flow data to be exported. Whether it is done in data plane or control 
plane is implementation specific and IMO does not belong to a IETF document.

As for your second problem, as many operators have pointed out, it is a common 
case to use BGP communities to represent geo locations at various 
granularities. So we need to provide them the tools to meet their requirements. 
Standardizing the IEs for BGP community is a good start.

Best regards,
Jie


-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com]
Sent: Friday, April 13, 2018 10:44 PM
To: rtg-...@ietf.org
Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; i...@ietf.org;
ops...@ietf.org; gen-art@ietf.org
Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Reviewer: Joel Halpern
Review result: Not Ready

This is both a gen-art re-review and a routing directorate requested review.

The revisions from draft-04 to -06 show some improvement.  However, I still
have serious problems with this work.

The primary problem is that this seems to violate the designed work
distribution in the IPFIX architecture.  The draft itself notes that the
correlation requested could be done in the collector.  Which is where
correlation is designed to be done.  Instead, it puts a significant new
processing load on the router that is delivering the IPFIX information.  For
example, if one delivers IPFIX from the router data plane, one either has to
modify the router architecture to include additional complex computed
information in the data plane architecture (a bad place to add complexity) or
one has to give up and move all the information through the control plane.
And even the control plane likely has to add complexity to its RIB logic, as it 
has
to move additional information from BGP to the common structures.

The secondary problem is that this additional work is justified for the router 
by
the claim that the unusual usage of applying community tags for geographical
location of customers is a common practice.  It is a legal practice.  And I
presume it is done somewhere or the authors would not be asking for it.   But
it is not common.

In short, since even the draft admits that this is not needed, I recommend
against publishing this document as an RFC.




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

Re: [Gen-art] 答复: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

There seem to be two separate issues.

The first issue is what information from BGP would one like to correlate 
with the traffic flows.  I understand that there is useful information. 
The motivation given in the draft seems to apply to more cases than I 
thought, but still it is of limited applicability.


More importantly is the question of whether the proposed method is the 
right way to get the information.  As the draft acknowledges, there are 
other ways to get the information.  Ways that do not need new router 
software much less modifications of the fast path.
There is an argument in the draft about timeliness.  At least for the 
use case document in the draft, that argument does not hold water.


Yours,
Joel

On 4/15/18 10:45 PM, Aijun Wang wrote:

Hi, Joel:

Can we consider this draft from other viewpoints? If the router can
report and correlate the traffic with its associated community, the
usage of the community to differentiate the customer, the service
category that be accessed and the geographical region etc. will be
flourished.

And currently, China Telecom has some internal usage regulation for
community to differentiate some important customers and the related
services.

Best Regards.

Aijun Wang

Network R and Operation Support Department

China Telecom Corporation Limited Beijing Research
Institute,Beijing, China.

*From:*Joel Halpern 

*Date:* 2018-04-13 22:44

*To:*rtg-...@ietf.org 

*CC:*draft-ietf-opsawg-ipfix-bgp-community@ietf.org 
; 
i...@ietf.org ; ops...@ietf.org 
; gen-art@ietf.org 


*Subject:* Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Reviewer: Joel Halpern

Review result: Not Ready

This is both a gen-art re-review and a routing directorate requested review.

The revisions from draft-04 to -06 show some improvement.  However, I still

have serious problems with this work.

The primary problem is that this seems to violate the designed work

distribution in the IPFIX architecture.  The draft itself notes that the

correlation requested could be done in the collector.  Which is where

correlation is designed to be done.  Instead, it puts a significant new

processing load on the router that is delivering the IPFIX information.  For

example, if one delivers IPFIX from the router data plane, one either has to

modify the router architecture to include additional complex computed

information in the data plane architecture (a bad place to add 
complexity) or


one has to give up and move all the information through the control 
plane.  And


even the control plane likely has to add complexity to its RIB logic, as 
it has


to move additional information from BGP to the common structures.

The secondary problem is that this additional work is justified for the 
router


by the claim that the unusual usage of applying community tags for 
geographical


location of customers is a common practice.  It is a legal practice.  And I

presume it is done somewhere or the authors would not be asking for 
it.   But


it is not common.

In short, since even the draft admits that this is not needed, I recommend

against publishing this document as an RFC.



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

Re: [Gen-art] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

randy, noting that the IETF has trouble with the geo-tagging of its 
addresses does not seem to have ANYTHING to do with demonstrating how 
widely used the geo-communities are.


If you want to make that case, make it.  But don't bring up red herrings.

As you note, it is up to the WG, not to me, what to ask for regarding 
this draft.  And it is up to the ADs to judge whether this is a good 
thing to standardize.


Yours,
Joel

On 4/15/18 6:53 PM, Randy Bush wrote:

Thus, again, you are not making a case for why the existing techniques
which are easier to implement and deploy are not sufficie3nt for the
problem.


correct.  i, and a couple of other ops, are making the case that
communities are fairly widely used for tagging geo loc at varying
granularities.  you are not required to agree.

and you can argue the rest with someone else.



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

Re: [Gen-art] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

Randy, I did suggest that one would update the offline data.
My point was that the draft claims taht extreme timliness is needed. 
For IP block geolocation, timeliness on the order of a day (much shorter 
than the several days before the IETF when the IETF block gets turned on 
somewhere.)


Thus, again, you are not making a case for why the existing techniques 
which are easier to implement and deploy are not sufficie3nt for the 
problem.


Yours,
Joel

On 4/15/18 6:28 PM, Randy Bush wrote:

I fone has geo-information, it is unlikely to change.


i guess you have never noticed when you are at ietf praha and your phone
says you are in seoul or whatever.  it takes non-trivial ops pain to get
ietf attendees geoloc to work; and sometimes we can't.

when you find yourself in a hole, first thing is to stop digging.

___
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] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

Thank you for that pointer.  It is informative.
I looked at a number of the entries (trying to pick larger ISPs as more 
likely to need more information.)
What i see is some ISPs doing what Randy Bush mentioned, marking 
regions.  I see a few ISPs that explicitly mark country (or in one case 
city).  I see some that mix several pieces of information including 
country in the same community, making it hard to perform what this I-D 
calls for (not impossible, just harder).  I do not see any indication of 
wide-spread consistency.


It appears that this is of use to a few ISPs.  I have never argued that 
no one wants this (the authors would not have written it if no one 
wanted it.)


From what I can tell reading this, the value requires significantly 
more precision than "region".


Also, one of the arguments for doing this in the router is that you can 
get more timely and precise correlation.  Except that for geolocation of 
address blocks, upstream correlation seems to be quite sufficiently 
stable and precise.  NLRI may come and go.  I fone has geo-information, 
it is unlikely to change.


Yours,
Joel


On 4/15/18 12:09 PM, heasley wrote:

Sun, Apr 15, 2018 at 02:52:43PM +, li zhenqiang:

Why do you think this is unusual and not common?


Possibly, with due respect, because he is not an operator?  While ASes often
do so internally, not all reveal it externally or not ubiquitously.  Browse
https://onestep.net/communities/ to find the geo tag values of various ASes.



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

Re: [Gen-art] [Uta] Genart last call review of draft-ietf-uta-smtp-tlsrpt-17

[Joel M. Halpern]

A reasonable perspective.  Could that be added to the document?

Yours,
Joel

On 3/8/18 6:33 PM, Viktor Dukhovni wrote:




On Mar 8, 2018, at 5:28 PM, Joel Halpern  wrote:

It is surprising in Section 3 Bullet 4 that reporting via email requires
that the report submitted use DKIM.  Particularly while ignoring any
security errors in communicating with the recipient domain.


Actually, this is not surprising.  The main security risk here is report spam,
that will drown the true signal in noise, making it impossible to notice real
validation failures or operate the service.

Therefore, the report origin domain must be authenticated via DKIM.  I'd
be tempted to go further and require a particular "selector" prefix that
is specifically chosen for "tlsrpt", so that with domains such as "gmail",
where anyone can get an email account, just being a user on the sending
system is not enough to be able to forge a DKIM authenticated report.
But that would create significant complications for the sender to make it
so, and so is probably not needed.

In summary, when sending reports the party that needs to be authenticated
is the sender domain, while the receiving domain is presumed operationally
compromised, and so should be exempt from any authentication requirements.



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

Re: [Gen-art] R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

[Joel M. Halpern]

Further comments in line, marked  ...  as some mail readers 
mangle the inclusion marking.
As a reminder, please work with your chair and sponsoring AD to 
determine when to submit changes.


Yours,
Joel

On 2/28/18 6:22 AM, Fioccola Giuseppe wrote:

Hi Joel,
Thanks for your detailed review! It is very useful.
My answers inline tagged as [GF]

Best Regards,

Giuseppe

-Messaggio originale-
Da: Joel Halpern [mailto:j...@joelhalpern.com]
Inviato: domenica 25 febbraio 2018 02:00
A: gen-art@ietf.org
Cc: l...@ietf.org; i...@ietf.org; 
draft-ietf-l2sm-l2vpn-service-model@ietf.org
Oggetto: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

Reviewer: Joel Halpern
Review result: On the Right Track

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-l2sm-l2vpn-service-model-08
Reviewer: Joel Halpern
Review Date: 2018-02-24
IETF LC End Date: 2018-03-26
IESG Telechat date: 2018-04-05

Summary: Given the number of Major and minor issues, this document is not yet 
ready for publication as a Proposed Standard RFC.

Major:
 Introduction: The phrasing of "an abstract model", "this model is not a
 configuration model..." creates some confusion in the reader as to whether
 this model represent the current state of service deliveyr, the desired
 state of service delivery (which would drive configuration) or both.
 Please clarify.

[GF]: Ok I understand and we can clarify this point in a new revision. This 
model is used to describe service intent or service requirements and 
characteristic associated with connectivity service. Consider that also in RFC 
8299 (L3SM) there is the same phrasing.


Thank you.  I think clarifying this will help the reader. 



 The "valid-provider-identifiers' distinguish between cloud-identifier and
 remote-carrier-identifier.  It i unclear why the VPN service provider
 should know or care whether the remote provider he is connecting with is a
 cloud provider, and another L2 service provider, or both.  And if it is
 both, which identifier should be used.

[GF]: Remote-carrrier-identifier is used in the NNI case, see the code within 
YANG module:
“
 leaf remote-carrier-name {
   when "derived-from-or-self(../../../site-vpn-flavor,"+
 "'l2vpn-svc:site-vpn-flavor-nni')" {
 description
   "Relevant when Site vpn flavor is
   site-vpn-flavor-nni.";
   }

”
[GF]: In the NNI case, the current VPN Service provider can connect to another 
L2VPN or Data Center network or Cloud Provider’s network. Please also see 
section 5.16 for NNI support details.
You are right, the VPN service provider doesn’t  care whether the remote 
provider is a cloud provider or L2VPN service provider. So remote carrier-name 
doesn’t need to distinguish cloud provider or L2VPN service provider, if you 
believe we should distinguish we can remove remote carrier name, we think it 
add complexity and note that remote carrier name is an optional parameter. 
Regarding cloud-identifier defined within “valid-provider-identifiers”, 
cloud-identifier is only applied to public cloud or internet access, while 
remote-carrier-name can be referred to private cloud/data center or another 
L2VPN. That’s why we use cloud-identifier within cloud-access.


 I did see the indirect references, that basically make these name 
lists a constraint on what values can be used in the other parts of the 
model.  That is effective.  What is unclear is why you have the 
different kinds of identifiers, as the distinctions are not very clear. 





 Also, it is very unclear how these identifiers will be used.  They
 presumably are names of something.  But of what?  As known to whom?
 Derived from where?  I do not see how a provider / customer pair using this
 model will know what values to use for this.

[GF]: We think one is name of the public cloud or internet access, the other is 
carrier name, they are different. We assume in this model to use “cloud access” 
to get access to public cloud or internet, we use “NNI” to get access to 
private cloud, data center or another L2VPN, therefore Cloud identifier should 
be known by both the current L2VPN Service provider and the customer. Remote 
Carrier name in NNI case should be known by the current L2VPN service provider 
it is connecting.


The point I was trying to get at, and probably muddled, is that the 
name a customer uses for some third party may not be the same as the 
name the service providers uses (although they will be similar.  Is 
Ericsson A.B. the same or different from Ericsson Inc. or 

Re: [Gen-art] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Joel M. Halpern]

Is this for one operator (still important, but not necessarily for 
standardization) or are there several operators who have expressed 
interest in this?


Yes, we do proactive standards.  But the IDR group, for example, tends 
to be very careful to see if interest is reflected in implementation.


In this case, given that what is proposed is a completely different use 
of the BGP communities, I think at least more clarity that this is only 
expected to be used for communities that match the purpose, and of how 
and why the vendors would implement the router-side logic.


To get back to the points I made in the review:

1) The document needs to be much clearer that it is about new 
communities whcih are expected to be defined for this use.  It needs to 
be clear if this is expected to be applied to communities put on by 
other AS, or only to communities provided by routers of the collecting 
AS.  The later leads to understandable configuration.  The former leads 
to questions about hos the meaning will be known.


2) The document needs to be clear and explicit about what processing it 
is expecting the router to provide, and how much configuration is needed 
to get the right things to happen.


Yours,
Joel

On 2/27/18 8:54 PM, li zhenqiang wrote:

Hi Joel,

This is Zhenqiang Li from China Mobile. The purpose of this doc is not 
to report the well-known communities, but the operator planed 
communities represent the groups of the customers, peers, 
the geographical and topological related information as stated in 
RFC4384, which is a common practice and also used in our field network.


When the exporter, i.e. router, receives the templete to report the 
communities, the exporter gets the information through BGP lookup using 
the corresponding source or destination IP of a traffic flow. The 
procedure for the exporter to get the community informaiton of a traffic 
flow is the same as it gets the AS information.


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*From:* Joel M. Halpern <mailto:j...@joelhalpern.com>
*Date:* 2018-02-12 00:37
*To:* Dongjie (Jimmy) <mailto:jie.d...@huawei.com>; gen-art@ietf.org
<mailto:gen-art@ietf.org>
*CC:* draft-ietf-opsawg-ipfix-bgp-community@ietf.org
<mailto:draft-ietf-opsawg-ipfix-bgp-community@ietf.org>;
ops...@ietf.org <mailto:ops...@ietf.org>
*Subject:* Re: Genart early review of
draft-ietf-opsawg-ipfix-bgp-community-04
This was a requested early review.  You folks can do as you deem best.
 From where I sit, it seems odd.  Most well-known communities do not
fit
the pattern of representing groups of sources or groups of destinations.
I presume the intent here is for this to be useful in some AS other
than
the one originating the communities.  Which makes it even harder to see
when it would apply.
I presume this is driven by having found that it would have helped in
some real-world situation?
I think the document would be helped by a clearer description of
when it
applies and what behavior is expected of the router (not just "the same
as that over there.")
Yours,
Joel
On 2/11/18 1:32 AM, Dongjie (Jimmy) wrote:
 > Hi Joel,
 >
 > Thanks for your review comments. Please see my replies inline:
 >
 >> -Original Message-
 >> From: Joel Halpern [mailto:j...@joelhalpern.com]
 >> Sent: Saturday, February 10, 2018 1:27 AM
 >> To: gen-art@ietf.org
 >> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org;
ops...@ietf.org
 >> Subject: Genart early review of
draft-ietf-opsawg-ipfix-bgp-community-04
 >>
 >> Reviewer: Joel Halpern
 >> Review result: Not Ready
 >>
 >> This is an early gen-art review of draft-ietf-opsawg-ipfix-bgp-04.
 >>
 >> The document is clear about what it is trying to do, and
readable.  It is not
 >> clear about how it expects this to actually work.
 >>
 >> However, I find the underlying concept confusing.
 >> 1) BGP Communities may sometimes represent subsets of traffic. 
But usually

 >> they represent tagging intended to influence routing which is
only indirectly
 >> related to meaningful subsets of traffic for TE purposes.  One
may be able to
 >> make an argument that this could better enable monitoring the
effects of some
 >> BGP communities.  But the draft does not make that argument.
 >
 > This depends on how the BGP communities are used by the
operators. Except some well-known communities, BGP communities are
used in a customized manner. In some cases, BGP communities indicate
the source and destination information of a group of tra

Re: [Gen-art] Genart last call review of draft-ietf-core-object-security-08

[Joel M. Halpern]

Yes, that is what I was looking for.
Thank you,
Joel

On 2/23/18 9:38 AM, Göran Selander wrote:


How about this (see the last and third to last edit):
https://github.com/core-wg/oscoap/commit/8f277d83

where the reference is made to COSE instead of AEAD?

Best
Göran


On 2018-02-23 15:32, "Joel Halpern Direct" <jmh.dir...@joelhalpern.com>
wrote:


I guess it is up to you.  Personally, I like the idea of the verify
description including some reference to how one actually does verify.
I will leave it to the authors and WG to decide what degree of clarity
is called for here.

Yours,
Joel

On 2/23/18 9:30 AM, Göran Selander wrote:

Hi Joel,

Thanks for quick feedback, inline.

On 2018-02-23 14:59, "Joel M. Halpern" <j...@joelhalpern.com> wrote:


In terms of my concerns, if Step 7 said "Verify and Decrypt the COSE
object using the Recipient Key as per RFC 5116 Section 2.2" that would
fill in the confusion for this reader.


Since the AEAD is used throughout the draft, in particular in other
parts
of this section I’m thinking that maybe we should add RFC 5116 to the
list
of specifications following "Readers are expected to be familiar with”
in
Section 1.1. Would that address your comment?

Thanks
Göran





Yours,
Joel

On 2/23/18 5:26 AM, Göran Selander wrote:

Hi Joel,

Thanks for your review. Comments inline.


On 2018-02-22 04:51, "Joel Halpern" <j...@joelhalpern.com> wrote:


Reviewer: Joel Halpern
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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-core-object-security-08
Reviewer: Joel Halpern
Review Date: 2018-02-21
IETF LC End Date: 2018-03-02
IESG Telechat date: 2018-03-08

Summary: This document is ready for publication as a Proposed
Standard
RFC

Major issues: N/A

Minor issues:
  In section 8.2 on verifying the request, step 5 says to
"compose"
the
  Additional Authentication Data.  I would have expected it to be
"verify"
  the Additional Authentication Data.  I could imagine that the
verification
  consists of composing what it should be, and then comparing with
what
is
  received.  But I do not see the comparison step.  is it
implicit in
some
  other step?  This occurs again in 8.4, so I presume I am simply
missing
  something.  This may suggest some clarification could be useful.


The AAD is indeed “composed" both on encrypting and decrypting side
from
data which needs to be known to the endpoint at the time when the AEAD
operation is performed. The authenticated decryption process is
described
in:

https://tools.ietf.org/html/rfc5116#section-2.2

So the verification consists of feeding the input, including the AAD,
to
the authenticated decryption which calculates the plain text or FAIL,
and
a failure may be - but is not necessarily - caused by wrong AAD.

The AD review also indicated that we should move the reference to RFC
5116
to an early section in the draft and that change is already included
in
the latest version on the CoRE WG Github.


Best regards
Göran







___
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-core-object-security-08

[Joel M. Halpern]

In terms of my concerns, if Step 7 said "Verify and Decrypt the COSE 
object using the Recipient Key as per RFC 5116 Section 2.2" that would 
fill in the confusion for this reader.


Yours,
Joel

On 2/23/18 5:26 AM, Göran Selander wrote:

Hi Joel,

Thanks for your review. Comments inline.


On 2018-02-22 04:51, "Joel Halpern"  wrote:


Reviewer: Joel Halpern
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-core-object-security-08
Reviewer: Joel Halpern
Review Date: 2018-02-21
IETF LC End Date: 2018-03-02
IESG Telechat date: 2018-03-08

Summary: This document is ready for publication as a Proposed Standard RFC

Major issues: N/A

Minor issues:
In section 8.2 on verifying the request, step 5 says to "compose" the
Additional Authentication Data.  I would have expected it to be
"verify"
the Additional Authentication Data.  I could imagine that the
verification
consists of composing what it should be, and then comparing with what
is
received.  But I do not see the comparison step.  is it implicit in
some
other step?  This occurs again in 8.4, so I presume I am simply
missing
something.  This may suggest some clarification could be useful.


The AAD is indeed “composed" both on encrypting and decrypting side from
data which needs to be known to the endpoint at the time when the AEAD
operation is performed. The authenticated decryption process is described
in:

https://tools.ietf.org/html/rfc5116#section-2.2

So the verification consists of feeding the input, including the AAD, to
the authenticated decryption which calculates the plain text or FAIL, and
a failure may be - but is not necessarily - caused by wrong AAD.

The AD review also indicated that we should move the reference to RFC 5116
to an early section in the draft and that change is already included in
the latest version on the CoRE WG Github.


Best regards
Göran



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

Re: [Gen-art] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Joel M. Halpern]

This was a requested early review.  You folks can do as you deem best.

From where I sit, it seems odd.  Most well-known communities do not fit 
the pattern of representing groups of sources or groups of destinations.
I presume the intent here is for this to be useful in some AS other than 
the one originating the communities.  Which makes it even harder to see 
when it would apply.
I presume this is driven by having found that it would have helped in 
some real-world situation?


I think the document would be helped by a clearer description of when it 
applies and what behavior is expected of the router (not just "the same 
as that over there.")


Yours,
Joel

On 2/11/18 1:32 AM, Dongjie (Jimmy) wrote:

Hi Joel,

Thanks for your review comments. Please see my replies inline:


-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com]
Sent: Saturday, February 10, 2018 1:27 AM
To: gen-art@ietf.org
Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; ops...@ietf.org
Subject: Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

Reviewer: Joel Halpern
Review result: Not Ready

This is an early gen-art review of draft-ietf-opsawg-ipfix-bgp-04.

The document is clear about what it is trying to do, and readable.  It is not
clear about how it expects this to actually work.

However, I find the underlying concept confusing.
1) BGP Communities may sometimes represent subsets of traffic.  But usually
they represent tagging intended to influence routing which is only indirectly
related to meaningful subsets of traffic for TE purposes.  One may be able to
make an argument that this could better enable monitoring the effects of some
BGP communities.  But the draft does not make that argument.


This depends on how the BGP communities are used by the operators. Except some 
well-known communities, BGP communities are used in a customized manner. In 
some cases, BGP communities indicate the source and destination information of 
a group of traffic flows. These are the major case this document is focusing 
on, as it would be helpful for operator to collect the traffic statistics based 
on BGP communities. Using BGP communities to influence routing is another 
popular use case. In that case, it may also be helpful to collect traffic 
statistic information related to the BGP communities, while the purpose may not 
be just for TE.

2) It is

unclear what this actually expects the router to do in generating this
information.
Reading between the lines, it seems that what is desired is for the router
control process to go through the IPFIX collected information before it is
exported, and add BGP community tags to the export information.
(Generating such information directly from the forwarding plane would place
significant load on the forwarding representation and processing, and on the
control logic to generate FIB information.)  Given that off-line BGP information
collection is a common practice, and that such information is common across
the AS, it would actually seem simpler to perform such processing and
aggregation offline rather than in the router.


The behavior of a router would be similar to its behavior with the existing BGP 
relevant IEs, e.g. bgpSourceAsNumber, bgpDestinationAsNumber, 
bgpNextHopIPv4Address, etc. Basically this is the aggregated traffic 
information collection model, in which the router aggregates the collected 
traffic information based on the IEs specified in the template, so that it can 
export much less information to the collector without losing the information 
the collector really cares about. Exporting aggregated traffic statistics has 
been widely used in the networks.
  
Note that the purpose of this mechanism is to export the aggregated traffic statistics information at the granularity specified by BGP communities, while BMP can used to collect the detailed information of BGP RIBs and BGP events, IMO they are designed for different purposes. Although it is possible to export all the non-aggregated traffic information to the collector, and let the collector to correlate them with the BGP communities, this can bring heavy burden to both the exporter and the collector.




If the IDR working group has not been consulted about this, I would strongly
recommend working with them as to whether this is actually useful information
to collect, and how and where to collect it. If the IDR working group does not
consider important to work on this, then that gives you useful information in
and of itself.


The IDR WG has been notified about the LC of this document, so far there is no 
objection received from them. We would like to encourage IDR people to review 
and give feedbacks to help improve this document. Whether the new IEs are 
useful or not should be determined in the OPSAWG.

Best regards,
Jie



___
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-kitten-rfc5653bis-06

[Joel M. Halpern]

Personal opinion:
Given that to my reading "must" is used on the document in both the RFC 
2119 sense and in a conventional English language sense, it would be 
worth clarifying the intention.  As such, I think it would be better to 
use the 8174 reference and go through changing the right ones to upper case.


Yours,
Joel

On 1/2/18 9:40 PM, Weijun Wang wrote:

Hi Joel and Ben

Author here.

I think I've removed the section because in fact none of the keywords appears as 
capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE 
usage of the key words have the defined special meanings".

I assume I'll need to go through the document and make some UPPERCASE and some 
not, depending on the actual meanings.

Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole 
document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all 
"must" and "required" in lowercase?

Thanks
Weijun



On Jan 3, 2018, at 9:49 AM, Joel M. Halpern <j...@joelhalpern.com> wrote:

Thanks Ben.  That would be good.
Yours,
Joel

On 1/2/18 8:38 PM, Benjamin Kaduk wrote:

Hi Joel,
On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote:

Reviewer: Joel Halpern
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 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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25

Summary: This document is ready for publication as a Proposed Standard RFC

Major issues: None

Minor issues:
 Although ID-Nits does not complain about it, I can find no reference to
 RFCs 2119 or 8174.  Some of the uses of "must" int he document are along
 the lines of "inherently follows", which is not normative language.  But
 other uses are clearly normative in structure.   It is unclear why the
 reference to RFC 2119 was removed as part of this update.

Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.
I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.
-Ben





___
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-kitten-rfc5653bis-06

[Joel M. Halpern]

Thanks Ben.  That would be good.
Yours,
Joel

On 1/2/18 8:38 PM, Benjamin Kaduk wrote:

Hi Joel,

On Tue, Jan 02, 2018 at 03:30:31PM -0800, Joel Halpern wrote:

Reviewer: Joel Halpern
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 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-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25

Summary: This document is ready for publication as a Proposed Standard RFC

Major issues: None

Minor issues:
 Although ID-Nits does not complain about it, I can find no reference to
 RFCs 2119 or 8174.  Some of the uses of "must" int he document are along
 the lines of "inherently follows", which is not normative language.  But
 other uses are clearly normative in structure.   It is unclear why the
 reference to RFC 2119 was removed as part of this update.


Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.

I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.

-Ben



___
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-intarea-probe-07

[Joel M. Halpern]

That would be fa reasoanble way to address my genart review question.
Yours,
Joel

On 12/6/17 11:13 AM, Ron Bonica wrote:

Stewart,

Having thought about it for a while, you may be right. PROBE was meant to be an 
IP tool. Pseudo-wire endpoints were an afterthought, and not a very good 
afterthought at that.

Let's remove the E-bit (aka P-bit) and limit Probe to querying the status of IP 
interfaces.

Ron



-Original Message-
From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Wednesday, December 6, 2017 6:24 AM
To: Ron Bonica <rbon...@juniper.net>; Joel M. Halpern
<j...@joelhalpern.com>; gen-art@ietf.org
Cc: draft-ietf-intarea-probe@ietf.org; int-a...@ietf.org; i...@ietf.org;
pals-cha...@tools.ietf.org; mpls-cha...@ietf.org; l2tpext-cha...@ietf.org; The
IESG <i...@ietf.org>
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07

I cannot quite work out from the document how this works, but if we are
going to PING non-IP interfaces I think the groups that work on those need
some time to reflect on the implications.

There are certainly a number of non-IP interfaces that may have Ethernet
addresses.

However, I am not sure from a quick look at the text how you would address
any interface running a PW other than Ethernet.

Bottom line, I think this needs to either preclude non-IP interfaces, or the
groups that work with non-IP interfaces need to think through the
implications, and possibly propose new identifier types.

- Stewart


On 04/12/2017 22:48, Ron Bonica wrote:

Joel,

The important piece of information is that this is a pseudowire endpoint.

These days, most pseudowire endpoints seem to be Ethernet. But some
aren't. There are still some legacy layer 2 pseudowires hanging around.


So, since we can't enumerate every type of pseudowire endpoint, we

might as well just call it a pseudowire endpoint and provide no further
information about the type.



Ron



-Original Message-----
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Monday, December 4, 2017 4:19 PM
To: Ron Bonica <rbon...@juniper.net>; gen-art@ietf.org
Cc: draft-ietf-intarea-probe@ietf.org; int-a...@ietf.org;
i...@ietf.org
Subject: Re: Genart telechat review of draft-ietf-intarea-probe-07

Thank you Ron.

On the E-bit (or P-Bit), is the important goal that it is a virtual
interface, that it is pseudowire, or ?  It might help there text
indicating what a receiver might do differently based on this bit being set

or unset.

Having said that, Ethernet Pseudowire is at least a clearer
distinction than just "Ethernet".  And as long as the bit has a clear
definition, any disagreement about what "should" be identified is clealry

NOT a show stopper.


Yours,
Joel

On 12/4/17 4:13 PM, Ron Bonica wrote:

Hi Joel,

Thanks for the review. Responses inline..

  Ron



-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com]
Sent: Thursday, November 30, 2017 4:45 PM
To: gen-art@ietf.org
Cc: draft-ietf-intarea-probe@ietf.org; int-a...@ietf.org;
i...@ietf.org
Subject: Genart telechat review of draft-ietf-intarea-probe-07

Reviewer: Joel Halpern
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

<https://urldefense.proofpoint.com/v2/url?u=https-




3A__trac.ietf.org_trac_gen_wiki_GenArtfaq=DwICaQ=HAkYuh63rsuhr

6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-




AWF2EfpHcAwrDThKP8=hKAAxSQXBFWxkxtwUUKzdYcvZ22_3zrp0OZhHK

V2AH4=X_Kje37D5HB_DdICxGgn_TkAqoXymCuJdJetUjwYPy4=>.

Document: draft-ietf-intarea-probe-07
Reviewer: Joel Halpern
Review Date: 2017-11-30
IETF LC End Date: 2017-12-13
IESG Telechat date: 2017-12-14

Summary: This document is almost ready for publication as a
Proposed Standard RFC.

Major issues:
   I can not determine from the text why two identification objects are
   sometimes allowed, or how they are to be used.  The texts
seems to indicate
   that they can be somehow combined to identify a single probed

interface.

   But I can not see how.

[RB ]
Good catch.

At one time I thought that this was necessary because IPv6
link-local

addresses are not necessarily unique to the node. So, you might need
to probe by IP address and something else (e.g., ifName). However,
ifName is unique to the node. So, one instance of the interface
identification object is enough.

I will remove that sentence.



Minor issues:
   In section 2.1 in describing the usage when the probed interface is
   identified by name or ifindex, the text refers to MIBII, RFC
2863.  I

would

   expect to see it refe

Re: [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07

[Joel M. Halpern]

Good enough.
Joel

On 12/4/17 5:48 PM, Ron Bonica wrote:

Joel,

The important piece of information is that this is a pseudowire endpoint. These 
days, most pseudowire endpoints seem to be Ethernet. But some aren't. There are 
still some legacy layer 2 pseudowires hanging around.

So, since we can't enumerate every type of pseudowire endpoint, we might as 
well just call it a pseudowire endpoint and provide no further information 
about the type.


 Ron



-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Monday, December 4, 2017 4:19 PM
To: Ron Bonica <rbon...@juniper.net>; gen-art@ietf.org
Cc: draft-ietf-intarea-probe@ietf.org; int-a...@ietf.org; i...@ietf.org
Subject: Re: Genart telechat review of draft-ietf-intarea-probe-07

Thank you Ron.

On the E-bit (or P-Bit), is the important goal that it is a virtual interface, 
that it
is pseudowire, or ?  It might help there text indicating what a receiver might
do differently based on this bit being set or unset.
Having said that, Ethernet Pseudowire is at least a clearer distinction than 
just
"Ethernet".  And as long as the bit has a clear definition, any disagreement
about what "should" be identified is clealry NOT a show stopper.

Yours,
Joel

On 12/4/17 4:13 PM, Ron Bonica wrote:

Hi Joel,

Thanks for the review. Responses inline..

 Ron



-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com]
Sent: Thursday, November 30, 2017 4:45 PM
To: gen-art@ietf.org
Cc: draft-ietf-intarea-probe@ietf.org; int-a...@ietf.org;
i...@ietf.org
Subject: Genart telechat review of draft-ietf-intarea-probe-07

Reviewer: Joel Halpern
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

<https://urldefense.proofpoint.com/v2/url?u=https-


3A__trac.ietf.org_trac_gen_wiki_GenArtfaq=DwICaQ=HAkYuh63rsuhr

6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-


AWF2EfpHcAwrDThKP8=hKAAxSQXBFWxkxtwUUKzdYcvZ22_3zrp0OZhHK

V2AH4=X_Kje37D5HB_DdICxGgn_TkAqoXymCuJdJetUjwYPy4=>.

Document: draft-ietf-intarea-probe-07
Reviewer: Joel Halpern
Review Date: 2017-11-30
IETF LC End Date: 2017-12-13
IESG Telechat date: 2017-12-14

Summary: This document is almost ready for publication as a Proposed
Standard RFC.

Major issues:
  I can not determine from the text why two identification objects are
  sometimes allowed, or how they are to be used.  The texts seems
to indicate
  that they can be somehow combined to identify a single probed

interface.

  But I can not see how.


[RB ]
Good catch.

At one time I thought that this was necessary because IPv6 link-local

addresses are not necessarily unique to the node. So, you might need to
probe by IP address and something else (e.g., ifName). However, ifName is
unique to the node. So, one instance of the interface identification object is
enough.


I will remove that sentence.




Minor issues:
  In section 2.1 in describing the usage when the probed interface is
  identified by name or ifindex, the text refers to MIBII, RFC 2863.  I

would

  expect to see it refer instead (or at least preferentially) to RFC 7223,
  the YANG model for the Interface stack.


[RB ]
Fair enough. I will make that change in the next version.



  The E bit in the Extended ICMP Echo reply seems a bit odd.  Shall we try

to

  encode all the possible interface types in this field?  Shall we try to
  distinguish Ethernet directly over fiber from Ethernet over ...?  What
  about an emulated Ethernet interface (pseudowire, etc.)  I do not
  understand why this is here, and fear it is ambiguous.

[RB ]
Looking back, I described that badly. This bit is set if the interface is a

pseudowire endpoint and it is running Ethernet.


Maybe I should call it the P-bit for Pseudowire endpoint. We don't need to

specify what type of pseudowire it is.


What do you think?



Nits/editorial comments:
  I find the description of the node containing the proxy interface as

being

  "the probed node" as being somewhat odd, as it is not the node

containing

  the probed interface.  I would have expected it to be called "the proxy
  node"?

[RB ]

Fair enough. I can make that change in the next revision.



  Very nitpicky: In section 4, the step reading "If the Code Field is equal
  to No Error (0) and the L-bit is clear, set the A-Bit." probably ought to
  say "otherwise, clear the A-bit."


[RB ]
Fair enough. I can make that change in the next revision.

Re: [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07

[Joel M. Halpern]

Thank you Ron.

On the E-bit (or P-Bit), is the important goal that it is a virtual 
interface, that it is pseudowire, or ?  It might help there text 
indicating what a receiver might do differently based on this bit being 
set or unset.
Having said that, Ethernet Pseudowire is at least a clearer distinction 
than just "Ethernet".  And as long as the bit has a clear definition, 
any disagreement about what "should" be identified is clealry NOT a show 
stopper.


Yours,
Joel

On 12/4/17 4:13 PM, Ron Bonica wrote:

Hi Joel,

Thanks for the review. Responses inline..

Ron



-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com]
Sent: Thursday, November 30, 2017 4:45 PM
To: gen-art@ietf.org
Cc: draft-ietf-intarea-probe@ietf.org; int-a...@ietf.org; i...@ietf.org
Subject: Genart telechat review of draft-ietf-intarea-probe-07

Reviewer: Joel Halpern
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-intarea-probe-07
Reviewer: Joel Halpern
Review Date: 2017-11-30
IETF LC End Date: 2017-12-13
IESG Telechat date: 2017-12-14

Summary: This document is almost ready for publication as a Proposed
Standard RFC.

Major issues:
 I can not determine from the text why two identification objects are
 sometimes allowed, or how they are to be used.  The texts seems to
indicate
 that they can be somehow combined to identify a single probed interface.
 But I can not see how.


[RB ]
Good catch.

At one time I thought that this was necessary because IPv6 link-local addresses 
are not necessarily unique to the node. So, you might need to probe by IP 
address and something else (e.g., ifName). However, ifName is unique to the 
node. So, one instance of the interface identification object is enough.

I will remove that sentence.




Minor issues:
 In section 2.1 in describing the usage when the probed interface is
 identified by name or ifindex, the text refers to MIBII, RFC 2863.  I would
 expect to see it refer instead (or at least preferentially) to RFC 7223,
 the YANG model for the Interface stack.


[RB ]
Fair enough. I will make that change in the next version.



 The E bit in the Extended ICMP Echo reply seems a bit odd.  Shall we try to
 encode all the possible interface types in this field?  Shall we try to
 distinguish Ethernet directly over fiber from Ethernet over ...?  What
 about an emulated Ethernet interface (pseudowire, etc.)  I do not
 understand why this is here, and fear it is ambiguous.

[RB ]
Looking back, I described that badly. This bit is set if the interface is a 
pseudowire endpoint and it is running Ethernet.

Maybe I should call it the P-bit for Pseudowire endpoint. We don't need to 
specify what type of pseudowire it is.

What do you think?



Nits/editorial comments:
 I find the description of the node containing the proxy interface as being
 "the probed node" as being somewhat odd, as it is not the node containing
 the probed interface.  I would have expected it to be called "the proxy
 node"?

[RB ]

Fair enough. I can make that change in the next revision.



 Very nitpicky: In section 4, the step reading "If the Code Field is equal
 to No Error (0) and the L-bit is clear, set the A-Bit." probably ought to
 say "otherwise, clear the A-bit."


[RB ]
Fair enough. I can make that change in the next revision.




___
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-pce-initiated-lsp-10

[Joel M. Halpern]

That would work for me.  I did conclude that the WG was happy with the 
term, which is why I considered it a nit.


Yours,
Joel

On 8/16/17 11:20 AM, Julien Meuric wrote:

Hi Joel,

Any issue with a request to initiate an LSP setup/teardown to a device? ;-)

I agree the name reads odd, but it has been there for some time now and
the WG seems to be fine with it. Besides, it does not prevent anyone to
add better wording in a patch to their favorite decoding software...

Thanks a lot for your review,

Julien


Aug. 11, 2017 - j...@joelhalpern.com:

Nits/editorial comments:
 It seems odd to have a message for the creation or deletion of an LSP
 called an LSP Initiate Request.


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

Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host

[Joel M. Halpern]

Works for me as a path forward.
Yours,
Joel

On 5/9/17 11:17 AM, Ron Bonica wrote:

Joel,

I think that you have hit the nail on the head. There is no clearly documented definition 
of BCP. In reality, the only enforced definition is that "a BCP is whatever the 
sitting IESG says is a BCP".

So, rather than arguing the point, why don't we just ask the IESG?

I will update the shepherds write-up noting that there was a question about 
whether this document should be BCP or INFO and send the document on to the 
IESG. We will defer to their judgement regarding the label.

Ron



-Original Message-----
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Monday, May 8, 2017 8:31 PM
To: Brzozowski, John <john_brzozow...@comcast.com>; Ron Bonica
<rbon...@juniper.net>; Brian E Carpenter <brian.e.carpen...@gmail.com>;
Van De Velde, Gunter (Nokia - BE/Antwerp)
<gunter.van_de_ve...@nokia.com>; draft-ietf-v6ops-unique-ipv6-prefix-
per-host@ietf.org; gen-art@ietf.org
Subject: Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host

John, I absolutely agree that this document describes behavior that is useful.
And it describes that behavior clearly.
One could, on that basis argue for PS status.
I think it better fits as informational.
I do not think it needs to be marked experimental.
I do think it should be published.

There are at least 3 definitions of BCP floating around out there.
One clearly does not apply (this is not documenting a widely practiced
current usage as far as I know.)  I understand that BCPs are not restricted to
that.
Another definition is a generally recommended behavior (even if folks do not
actually do it, cf BCP 38). I do not think that definition applies to this
document.
The third, and only enforced definition, is "what the IESG says is a BCP."  Not
a very helpful definition, but it is the actual one in use.

Which is why I ended my note by saying that I leave it to the IESG.

Yours,
Joel

On 5/8/17 8:04 PM, Brzozowski, John wrote:

Joel,

Please send the criteria for BCP v Informational so we can all evaluate

accordingly.


The document describes the *behavior* that is expected by UEs based on

the network configuration.  This was deliberate, not accidental or assumed.  I
am not sure there is anything to disagree about, data pertaining to device
behavior is clear and well known.


John
+1-484-962-0060

-Original Message-
From: Joel Halpern <j...@joelhalpern.com>
Date: Monday, May 8, 2017 at 10:57
To: Ronald Bonica <rbon...@juniper.net>, Brian Carpenter
<brian.e.carpen...@gmail.com>, Gunter Van de Velde
<gunter.van_de_ve...@nokia.com>,
"draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org"
<draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org>,
"gen-art@ietf.org" <gen-art@ietf.org>
Subject: Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host
Resent-From: <alias-boun...@ietf.org>
Resent-To: <john_brzozow...@comcast.com>, Gunter Van de Velde
<gunter.van_de_ve...@nokia.com>, Ronald Bonica

<rbon...@juniper.net>,

<l...@asgard.org>, <fredbaker.i...@gmail.com>, <bcla...@cisco.com>,
<war...@kumari.net>, Ronald Bonica <rbon...@juniper.net>
Resent-Date: Monday, May 8, 2017 at 10:57

I do not think Brian's proposal addresses the issue.
Either this is indeed a Best / Recommended Current Practice, or it isn't.
All RFCs are optional.  So saying that this is optional does not seem to
help.

It seems very odd to defend the status on the basis that it was part of
a compromise.
To me, the document still reads like a conventional informational RFC.
To make it a BCP, in my view, it would have to describe the context in
which this was actually a recommended behavio.  I doubt we actually

have

agreement on that.
As far as I can tell, we do have agreement on this description of how to
do this when you want to.  Which is what Informational RFCs are for.

In the end, this is up to the IESG.

Yours,
Joel

On 5/8/17 10:28 AM, Ron Bonica wrote:
> Joel,
>
> Are you OK with the change that Brian recommends, below?
>
>   Ron
>
>
>> -Original Message-
>> From: Ron Bonica
>> Sent: Saturday, May 6, 2017 8:36 PM
>> To: 'Brian E Carpenter' <brian.e.carpen...@gmail.com>; Van De

Velde,

>> Gunter (Nokia - BE/Antwerp) <gunter.van_de_ve...@nokia.com>;

draft-

>> ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org; gen-art@ietf.org
>> Subject: RE: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host
>>
>> Wfm
>>
>> Joel, are you ok with this?
>>
>>  

Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host

[Joel M. Halpern]

John, I absolutely agree that this document describes behavior that is 
useful.  And it describes that behavior clearly.

One could, on that basis argue for PS status.
I think it better fits as informational.
I do not think it needs to be marked experimental.
I do think it should be published.

There are at least 3 definitions of BCP floating around out there.
One clearly does not apply (this is not documenting a widely practiced 
current usage as far as I know.)  I understand that BCPs are not 
restricted to that.
Another definition is a generally recommended behavior (even if folks do 
not actually do it, cf BCP 38). I do not think that definition applies 
to this document.
The third, and only enforced definition, is "what the IESG says is a 
BCP."  Not a very helpful definition, but it is the actual one in use.


Which is why I ended my note by saying that I leave it to the IESG.

Yours,
Joel

On 5/8/17 8:04 PM, Brzozowski, John wrote:

Joel,

Please send the criteria for BCP v Informational so we can all evaluate 
accordingly.

The document describes the *behavior* that is expected by UEs based on the 
network configuration.  This was deliberate, not accidental or assumed.  I am 
not sure there is anything to disagree about, data pertaining to device 
behavior is clear and well known.

John
+1-484-962-0060

-Original Message-
From: Joel Halpern 
Date: Monday, May 8, 2017 at 10:57
To: Ronald Bonica , Brian Carpenter , Gunter Van de Velde 
, "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" 
, "gen-art@ietf.org" 
Subject: Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host
Resent-From: 
Resent-To: , Gunter Van de Velde , Ronald Bonica 
, , , , 
, Ronald Bonica 
Resent-Date: Monday, May 8, 2017 at 10:57

I do not think Brian's proposal addresses the issue.
Either this is indeed a Best / Recommended Current Practice, or it isn't.
All RFCs are optional.  So saying that this is optional does not seem to
help.

It seems very odd to defend the status on the basis that it was part of
a compromise.
To me, the document still reads like a conventional informational RFC.
To make it a BCP, in my view, it would have to describe the context in
which this was actually a recommended behavio.  I doubt we actually have
agreement on that.
As far as I can tell, we do have agreement on this description of how to
do this when you want to.  Which is what Informational RFCs are for.

In the end, this is up to the IESG.

Yours,
Joel

On 5/8/17 10:28 AM, Ron Bonica wrote:
> Joel,
>
> Are you OK with the change that Brian recommends, below?
>
>   Ron
>
>
>> -Original Message-
>> From: Ron Bonica
>> Sent: Saturday, May 6, 2017 8:36 PM
>> To: 'Brian E Carpenter' ; Van De Velde,
>> Gunter (Nokia - BE/Antwerp) ; draft-
>> ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org; gen-art@ietf.org
>> Subject: RE: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host
>>
>> Wfm
>>
>> Joel, are you ok with this?
>>
>>   Ron
>>
>>
>>> -Original Message-
>>> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
>>> Sent: Friday, May 5, 2017 4:06 PM
>>> To: Ron Bonica ; Van De Velde, Gunter (Nokia -
>>> BE/Antwerp) ; draft-ietf-v6ops-
>> unique-
>>> ipv6-prefix-per-host@ietf.org; gen-art@ietf.org
>>> Subject: Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host
>>>
>>> s/The Best Current Practice documented in this note is/The optional
>>> Best Current Practice documented in this note is/
>>>
>>> Regards
>>>Brian
>>>
>>> On 06/05/2017 02:58, Ron Bonica wrote:
 Gunter,

 Thanks much. A brief chat with Joel may clear this up.

Ron


> -Original Message-
> From: Van De Velde, Gunter (Nokia - BE/Antwerp)
> [mailto:gunter.van_de_ve...@nokia.com]
> Sent: Friday, May 5, 2017 2:47 AM
> To: Ron Bonica ;
> draft-ietf-v6ops-unique-ipv6-prefix-
> per-host@ietf.org; gen-art@ietf.org
> Subject: Re: draft-ietf-v6ops-unique-ipv6-prefix-per-host
>
> Hi Ron, Gen-art directorate,
>
> I’m checking with John on the most 

Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host

[Joel M. Halpern]

I do not think Brian's proposal addresses the issue.
Either this is indeed a Best / Recommended Current Practice, or it isn't.
All RFCs are optional.  So saying that this is optional does not seem to 
help.


It seems very odd to defend the status on the basis that it was part of 
a compromise.

To me, the document still reads like a conventional informational RFC.
To make it a BCP, in my view, it would have to describe the context in 
which this was actually a recommended behavio.  I doubt we actually have 
agreement on that.
As far as I can tell, we do have agreement on this description of how to 
do this when you want to.  Which is what Informational RFCs are for.


In the end, this is up to the IESG.

Yours,
Joel

On 5/8/17 10:28 AM, Ron Bonica wrote:

Joel,

Are you OK with the change that Brian recommends, below?

  Ron



-Original Message-
From: Ron Bonica
Sent: Saturday, May 6, 2017 8:36 PM
To: 'Brian E Carpenter' ; Van De Velde,
Gunter (Nokia - BE/Antwerp) ; draft-
ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org; gen-art@ietf.org
Subject: RE: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host

Wfm

Joel, are you ok with this?

  Ron



-Original Message-
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
Sent: Friday, May 5, 2017 4:06 PM
To: Ron Bonica ; Van De Velde, Gunter (Nokia -
BE/Antwerp) ; draft-ietf-v6ops-

unique-

ipv6-prefix-per-host@ietf.org; gen-art@ietf.org
Subject: Re: [Gen-art] draft-ietf-v6ops-unique-ipv6-prefix-per-host

s/The Best Current Practice documented in this note is/The optional
Best Current Practice documented in this note is/

Regards
   Brian

On 06/05/2017 02:58, Ron Bonica wrote:

Gunter,

Thanks much. A brief chat with Joel may clear this up.

   Ron



-Original Message-
From: Van De Velde, Gunter (Nokia - BE/Antwerp)
[mailto:gunter.van_de_ve...@nokia.com]
Sent: Friday, May 5, 2017 2:47 AM
To: Ron Bonica ;
draft-ietf-v6ops-unique-ipv6-prefix-
per-host@ietf.org; gen-art@ietf.org
Subject: Re: draft-ietf-v6ops-unique-ipv6-prefix-per-host

Hi Ron, Gen-art directorate,

I’m checking with John on the most optimal way forward. While I am
not that keen on the BCP status of the document, it was part of a
motivation to split up the original draft on the subject discussing
community wifi networks from the address related aspects. John and
I will have a discussion on the subject and propose a path to
resolution of

the issue mentioned by gen-art.


G/

On 04/05/2017, 21:57, "Ron Bonica"  wrote:

Folks,

The following is status for draft-ietf-v6ops-unique-ipv6-prefix-per-

host:


- WG last call complete
- OPSDIR, GENART and INTDIR reviews complete
- write-up complete

The following issue was raised in the GENART Review:

" The proposed status seems questionable.  We as a community
are not recommending that operators assign unique prefixes to hosts.
This document is saying "if you want to do that, here is a way,
using existing tools, to make that work."  The document also
recommends specific setting of other flags (the O flag in the RA,
for example) that are not closely coupled to the particular topic.
This looks like an ordinary Informational RFC.  I would have no
concern with this

being published with that label."


Could the authors please address this issues. As soon as they
have done so, we can send it to the IESG for publication.


Ron




___
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] Review of draft-ietf-ippm-twamp-time-format-03

[Joel M. Halpern]

Yes, that makes the relationship of the conditions significantly clearer.
Thank you,
Joel

On 3/3/17 5:46 PM, Greg Mirsky wrote:

Hi Joel,
thank you for your thorough review and the most helpful comments. I've
did s/proposal/specification/ through the document. As for the section
2.1 would the following text be clearer:

The rules of setting timestamp flags in
   Modes field in server greeting and Set-Up-Response messages and
   interpreting them are as follows:

   o  If the Session-Receiver supports this extension, then the Server
  that establishes test sessions on its behalf MUST set PTPv2
  Timestamp flag to 1 in the server greeting message per the
  requirement listed in Section 2.  Otherwise, the PTPv2 Timestamp
  flag will be set to 0 to indicate that the Session-Reciever
  interprets only NTP format.

   o  If the Control-Client receives greeting message with the PTPv2
  Timestamp flag set to 0, then the Session-Sender MUST use NTP
  format for timestamp in the test session and Control-Client SHOULD
  set PTPv2 Timestamp flag to 0 in accordance with [RFC4656].  If
  the Session-Sender cannot use NTP timestamps, then the Control-
  Client SHOULD close the TCP connection associated with the OWAMP-
  Control session.

   o  If the Control-Client receives greeting message with the PTPv2
  Timestamp flag set to 1 and the Session-Sender can set timestamp
  in PTPv2 format, then the Control-Client MUST set the PTPv2
  Timestamp flag to 1 in Modes field in the Set-Up-Response message
  and the Session-Sender MUST use PTPv2 timestamp format.

   o  If the Session-Sender doesn't support this extension and can set
  timestamp only in NTP format, then the PTPv2 Timestamp flag in
  Modes field in the Set-Up-Response message will be set to 0 as
  part of Must Be Zero and the Session-Sender use NTP format.

Regards,

Greg


On Thu, Mar 2, 2017 at 8:45 PM, Joel Halpern > wrote:

Reviewer: Joel Halpern
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-ippm-twamp-time-format-??
Reviewer: Joel Halpern
Review Date: 2017-03-02
IETF LC End Date: 2017-03-15
IESG Telechat date: Not scheduled for a telechat

Summary:

Major issues:

Minor issues:
The wording of the behavioral requirements for signaling in
section 2.1 is atypical for IETF documents (and in my view makes it
harder for the reader to follow.)  The rules are listed as separate
rules, but they are actually sequential steps that must be test in
order, exiting the process if the condition for each step is met.  But
it does not actually say that.

Nits/editorial comments:
Section 2.3 refers to this as a proposal.  It is a specification,
not a proposal.  Please reword.





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

Re: [Gen-art] [Pce] Review of draft-ietf-pce-stateful-pce-18

[Joel M. Halpern]

So it is intentional that this draft prohibits that behavior (PCE driven 
establishment)?


Yours,
Joel

On 2/16/17 11:35 PM, Dhruv Dhody wrote:

Hi Joel,

Regarding your comment -


Is the intention to prohibit the driving
of LSP creation from the PCE?


This capability is described in -
https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 (document 
expired recently, authors should refresh it)

Thanks,
Dhruv


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Joel Halpern
Sent: 17 February 2017 09:08
To: gen-art@ietf.org
Cc: draft-ietf-pce-stateful-pce@ietf.org; p...@ietf.org; i...@ietf.org
Subject: [Pce] Review of draft-ietf-pce-stateful-pce-18

Reviewer: Joel Halpern
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-pce-stateful-pce-??
Reviewer: Joel Halpern
Review Date: 2017-02-16
IETF LC End Date: 2017-02-28
IESG Telechat date: 2017-03-16

Summary:

Major issues:

Minor issues:
   At the end of section 5.4, the text talks about a PCE accepting status
updates even if the  stateful capability has not been negotiated.  Which is
fine.  But as written, the text seems to say that doing so means that the
PCE will be able to "build and maintain an up to date view of the state of
the PCC's LSPs".  However, if the capability has not been negotiated, I do
not see how the PCE can count on getting full and timely state reports.  Trying
to infer why a PCC is sending such a report in the absence of the agreement
seems problematic.

This comment may be a misunderstanding or mis-expectation on my part.
I would have expected one of the ways o using an active PCE is to have the
PCE decide (under suitable circumstances) that an LSP is needed between two
PCCs.  As far as I can tell, the text in section
5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP Update
Request (in a PCUpd message) for an LSP that has been delegated to it.  At
that point I thought that a PCC could delegate a block of unsetup LSPs to
the PCE.  But then looking at 5.8.2, the text states that for each delegation,
the PCC must request an initial path.  That seems to prohibit delegating a
block of LSPs for future updates.  Is the intention to prohibit the driving
of LSP creation from the PCE?

I have looked but I can not find the text explaining the significance
and use of the Symbolic path name.  It is mandated by the draft.  There seems
to be an implicit assumption taht it is needed by the PCE.  If the explanation
of how or why it is needed is not present, it should be.

Nits/editorial comments:
Should the text on the S bit in section 7.3 (the LSP Object
definition) note that it should be set to 0 on all messages sent by the PCE?
Should that also be stated for the R bit?  And the O bits?

  Section 9.2 seems very odd.  It states that the IETF "SHOULD" do some
additional work.  I understand why teh work is needed.  But this does not
seem to match the RFC 2119 meaning of SHOULD as it does not apply to eitehr
the implementor or the implementation.


___
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] Review of draft-ietf-bfcpbis-sdp-ws-uri-07

[Joel M. Halpern]

Yes, those fixes ddress my concerns.  Thank you.
Joel

On 1/3/17 3:36 AM, Ram Mohan R (rmohanr) wrote:

Hi Joel,

Thanks for your response. Please see inline

-Original Message-
From: Joel Halpern 
Date: Saturday, 24 December 2016 at 4:45 AM
To: "gen-art@ietf.org" 
Cc: "bfcp...@ietf.org" , "i...@ietf.org" , 
"draft-ietf-bfcpbis-sdp-ws-uri@ietf.org" 
Subject: Review of draft-ietf-bfcpbis-sdp-ws-uri-07
Resent-From: 
Resent-To: , , , 
, , , , Charles Eckel 

Resent-Date: Saturday, 24 December 2016 at 4:45 AM

Reviewer: Joel Halpern
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-bfcpbis-sdp-ws-uri-??
Reviewer: Joel Halpern
Review Date: 2016-12-23
IETF LC End Date: 2017-01-12
IESG Telechat date: 2017-01-19

Summary: This document is ready for publication as a Proposed Standard
RFC.  I have a few minor comments that should be considered s they may
improve future understanding of the document.

Major issues: None

Minor issues:
In reading section 4.2 and 4.3, I believe I can guess at certain
intended behaviors, but it is not as clearly stated as I think is
desirable.  There is also one odd statement in section 4.3

Taking the odd statement first, the text in section 4.3 refers the
active answerer "towards
   the IP address and port of the offerer".  But when WebSockets is
used, one does not connect to the IP address and port, but to the URI
specified.

 I will replace the text as below:

EXISTING:
Towards the IP address and port of the offerer using the procedures described
   in [RFC6455]

NEW:
Towards the URI specified in a=ws-uri or a=wss-uri attribute using procedures 
described
   in [RFC6455]

I believe that the intent in 4.2 and 4.3 is that whichever side
will be "passive" is required to provide an a=ws-uri or a=wss-uri so
that the other side can establish the connection to the URI.  But
section 4.2 does not say that.


EXISTING:
   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection), unless the offerer insists on being a receiver of an
   incoming connection, in which case the offerer SHOULD use a value of
   "passive".  The offerer MUST NOT assign an SDP "setup" attribute with
   a "holdconn" value.

NEW:
   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection), unless the offerer insists on being a receiver of an
   incoming connection, in which case the offerer SHOULD use a value of
   "passive".  The offerer MUST NOT assign an SDP "setup" attribute with
   a "holdconn" value. If the “setup” attribute has a value “passive” it MUST 
also
have URI in the a=ws-uri or a=wss-uri attribute.

 And the text in section4.3 that talks
about providing the URI in the a= does not qualify whether it is
required with active, passive, or both.


NEW:
If the answers assigns SDP “setup” attribute with “passive”, then it MUST have 
URI in either
a=ws-uri or a=wss-uri attribute.

Does this look good and makes it more clear ?

Regards,
Ram

Nits/editorial comments:  N/A






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

Re: [Gen-art] Review of draft-mohali-dispatch-cause-for-service-number-12

[Joel M. Halpern]

At this point I will defer to the relevant ADs.
As far as I can tell, although the entry was created by an Informational 
RFC, the registry still claims that it is standards track.
And since this document is defining behavior, it behaves more like a 
standards track document than an Informational one.


But it is up to you folks.  In teh end, all I can do is raise the 
question, not decide it :-)


Yours,
Joel

On 12/15/16 11:51 PM, Ben Campbell wrote:



On Dec 15, 2016, at 10:35 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:

I see your point about this adding a value to the entry created by RFC 4458.
Is there a reason this can not simply be PS?  The fact that 4458 is 
Informational does not, as far as I can tell, justify continuing the error.  
While this is for a 3GPP usage, it appears to have been reviewed by the 
Dispatch WG sufficiently to justify PS.
One could argue that there is a down-ref issue,
but the fact that the field is in a standards-track required registry would 
seem to make that a moot point.



Do you think it makes sense to make some new values for “cause” into a proposed 
standard when “cause” itself is informational?  That seems like a pretty big 
downref issue, as such issues go. (For the record, I could be convinced to 
re-run this LC as PS, but I suspect that would lead to objections in the 
opposite direction.)

Right now, the situation is a standards-action registry with a informational 
entry. That’s clearly broken, but I’m not sure that _this_ draft is the place 
to fix it.

Also, if it makes any difference—even there there was discussion in dispatch, 
this is not a dispatch work item.


Yours,
Joel

PS: It would seem that WG discussion of that sort is something we would like to 
see in Shepherd writeups.


There’s two paragraphs on the subject in section (1) of the shepherd writeup 
:-)  (but it wasn’t a working group discussion per se.)

Thanks!

Ben.



On 12/15/16 11:28 PM, Ben Campbell wrote:

Hi Joel,

Thanks for the comments. There has been a fair amount of discussion
about the status of the draft. The situation is clearly not optimal, and
I welcome input on how to straighten it out.

The rational so far has been that this draft updates RFC 4588, which is
informational. It adds some additional values and related semantics for
the "cause" parameter from 4588. It does not register new parameters;
rather it adds itself as a reference in the existing "cause"
registration. This is mainly a courtesy to readers. (There is no
sub-registry for "cause" parameter values.) We might could get by
without that change, since in a perfect world people following the IANA
reference to 4588 would notice the "Updated by..." tag.

The gotcha is that RFC 4588 would not be possible as an informational
today; it would not have standing to register the "cause" parameter. But
at the time it was published, there was a lack of clarity around the
"standards action" policy for the SIP URI parameters registry. Making
the new values from _this_ draft standards track, when the parameter
itself is not, doesn't seem appropriate. We had some discussion about
whether we should promote 4588 to PS, but there was not consensus to do
so when it was published, and I don't see reason to expect that to have
changed.

This draft is primarily intended to meet a need in 3GPP, where I
understand they are effectively already doing this. Would it help to
more tightly scope this as "Here's something 3GPP is doing..." rather
than as a general mechanism?

Thanks!

Ben.

On 15 Dec 2016, at 21:57, Joel Halpern wrote:


Reviewer: Joel Halpern
Review result: Ready with Issues

Major:
   This document defines a new code for use in SIP, and specifies new
behavior both for the code itself and for its use in history-info.  I
am thus confused as to how this can be an informational RFC.  It looks
like it either Proposed Standard or experimental.  Yes, I see that RFC
4458, which this updates is Informational.  But just because we did it
wrong before does not make that behavior correct now.  In addition to
my understanding of the roles of different RFCs, I note that RFC 3969
and the IANA registry both state that this assignment must be made by
a standards track RFC.

Minor:
  Given our emphasis on IPv6 over IPv4, would it not make sense for
the examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)





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

Re: [Gen-art] Review of draft-mohali-dispatch-cause-for-service-number-12

[Joel M. Halpern]

I see your point about this adding a value to the entry created by RFC 4458.
Is there a reason this can not simply be PS?  The fact that 4458 is 
Informational does not, as far as I can tell, justify continuing the 
error.  While this is for a 3GPP usage, it appears to have been reviewed 
by the Dispatch WG sufficiently to justify PS.
One could argue that there is a down-ref issue, but the fact that the 
field is in a standards-track required registry would seem to make that 
a moot point.


Yours,
Joel

PS: It would seem that WG discussion of that sort is something we would 
like to see in Shepherd writeups.


On 12/15/16 11:28 PM, Ben Campbell wrote:

Hi Joel,

Thanks for the comments. There has been a fair amount of discussion
about the status of the draft. The situation is clearly not optimal, and
I welcome input on how to straighten it out.

The rational so far has been that this draft updates RFC 4588, which is
informational. It adds some additional values and related semantics for
the "cause" parameter from 4588. It does not register new parameters;
rather it adds itself as a reference in the existing "cause"
registration. This is mainly a courtesy to readers. (There is no
sub-registry for "cause" parameter values.) We might could get by
without that change, since in a perfect world people following the IANA
reference to 4588 would notice the "Updated by..." tag.

The gotcha is that RFC 4588 would not be possible as an informational
today; it would not have standing to register the "cause" parameter. But
at the time it was published, there was a lack of clarity around the
"standards action" policy for the SIP URI parameters registry. Making
the new values from _this_ draft standards track, when the parameter
itself is not, doesn't seem appropriate. We had some discussion about
whether we should promote 4588 to PS, but there was not consensus to do
so when it was published, and I don't see reason to expect that to have
changed.

This draft is primarily intended to meet a need in 3GPP, where I
understand they are effectively already doing this. Would it help to
more tightly scope this as "Here's something 3GPP is doing..." rather
than as a general mechanism?

Thanks!

Ben.

On 15 Dec 2016, at 21:57, Joel Halpern wrote:


Reviewer: Joel Halpern
Review result: Ready with Issues

Major:
This document defines a new code for use in SIP, and specifies new
behavior both for the code itself and for its use in history-info.  I
am thus confused as to how this can be an informational RFC.  It looks
like it either Proposed Standard or experimental.  Yes, I see that RFC
4458, which this updates is Informational.  But just because we did it
wrong before does not make that behavior correct now.  In addition to
my understanding of the roles of different RFCs, I note that RFC 3969
and the IANA registry both state that this assignment must be made by
a standards track RFC.

Minor:
   Given our emphasis on IPv6 over IPv4, would it not make sense for
the examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)


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

[Gen-art] Review: draft-ietf-dnsop-resolver-priming-09

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dnsop-resolver-priming-09
Initializing a DNS Resolver with Priming Queries
Reviewer: Joel M. Halpern
Review Date: 30-October-2016
IETF LC End Date: 10-November-2016
IESG Telechat date: (if known)

Summary: This document is ready for publication as a BCP.

Major issues:

Minor issues:

Nits/editorial comments:

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

Re: [Gen-art] Review: draft-bbf-bbf-urn-02

[Joel M. Halpern]

Thanks Barbarra.

With regard to the assignment process text, what you have would work.  I 
would suggest dropping the text about membership and simply talking 
about going through the BBF document creation and approval process.


Yours,
Joel

On 10/27/16 12:53 PM, STARK, BARBARA H wrote:

Hi Joel,


Major issues:
 RFC 3406 states that the namespace considerations section should indicate
why a new namespace is needed.  While this is pretty obvious, the text does
not actually say anything in that section to explain it.
 In particular, I would expect that section to explain why 3 NIDs are needed
rather than just 1.


Thanks for the comments. I propose adding the following text at the end of Namespace 
Considerations (the mention of the name change is part of a proposal to resolve a 
separate comment asking how "dslforum-org" relates to BBF):
   Three NIDs are defined. The "broadband-forum-org" and "dslforum-org"
   (Broadband Forum changed its name from DSL Forum in 2008) NIDs have
   been used for many years by BBF without formal registration. As they are
   referenced by multiple BBF specifications currently in common use, BBF is
   requesting to formalize them. The new "bbf" NID will be used for new work 
efforts.


Minor issues:
 The template in RFC 3406 indicates the the section in each NID on the
Process of identifier assignment should "detail the mechanism and or
authorities for assigning URNs to resources."  The draft simply says that the
BBF will provide procedures.  Do those procedures exist?  If not, there seems
to be a minor problem.  If they do exist, it would seem sensible to include a
pointer to the place where the BBF publicly documents those procedures, so
that people using this information who might want to register something can
understand what the rules and expectations are. (I realize that the RFC 6289
example this is based on did not include such a pointer, which is why I am
making this a minor comment instead of a major one.)


I'm struggling a bit with this one in trying to figure out what's the best thing to say here. 
At this point in time, URN assignments only happen through creation of a BBF document that 
identifies the URN. BBF processes for document creation are published on the members-only part 
of the website, and only BBF members can participate in creating a BBF document. There is 
currently no plan to allow non-members to register URNs. There is also no plan to allow BBF 
members to register URNs for their own use (creating a BBF document requires interest and 
participation from at least 3 different companies). Would it be appropriate to say "BBF 
procedures for URN assignment are noted at [BBF-RESOURCES] 
" and on that page explain that URN 
assignment requires BBF membership and going through the BBF project and document processes?

Thanks again,
Barbara



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

[Gen-art] Review: draft-bbf-bbf-urn-02

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-bbf-bbf-urn-02
Uniform Resource Name (URN) Namespaces for Broadband Forum
Reviewer: Joel M. Halpern
Review Date: 14-October-2016
IETF LC End Date: 4-November-2016
IESG Telechat date: N/A

Summary: This document is almost ready for publication as an 
Informational RFC.


Major issues:
RFC 3406 states that the namespace considerations section should 
indicate why a new namespace is needed.  While this is pretty obvious, 
the text does not actually say anything in that section to explain it.
In particular, I would expect that section to explain why 3 NIDs 
are needed rather than just 1.



Minor issues:
The template in RFC 3406 indicates the the section in each NID on 
the Process of identifier assignment should "detail the mechanism and or 
authorities for assigning URNs to resources."  The draft simply says 
that the BBF will provide procedures.  Do those procedures exist?  If 
not, there seems to be a minor problem.  If they do exist, it would seem 
sensible to include a pointer to the place where the BBF publicly 
documents those procedures, so that people using this information who 
might want to register something can understand what the rules and 
expectations are. (I realize that the RFC 6289 example this is based on 
did not include such a pointer, which is why I am making this a minor 
comment instead of a major one.)


Nits/editorial comments:

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

[Gen-art] Review: draft-ietf-tictoc-multi-path-synchronization-05

[Joel M. Halpern]

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-tictoc-multi-path-synchronization-05
Multi-Path Time Synchronization
Reviewer: Joel Halpern
Review Date: 15-Sept-2016
IETF LC End Date: 28-Sept-2016
IESG Telechat date: 29-Sept-2016

Summary: This document is ready for publication as an Experimental RFC

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

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

[Gen-art] review: draft-ietf-6man-deprecate-atomfrag-generation-07

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-6man-deprecate-atomfrag-generation-07
Generation of IPv6 Atomic Fragments Considered Harmful
Reviewer: Joel M. Halpern
Review Date: 11-August-2016
IETF LC End Date: 22-August-2016
IESG Telechat date: 1-Sept-2016

Summary: This document is ready for publication as an Informational RFC.

Major issues: N/A

Minor issues: N/A

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

[Gen-art] Review: draft-ietf-avtcore-rfc5764-mux-fixes-10

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-avtcore-rfc5764-mux-fixes-10
Multiplexing Scheme Updates for Secure Real-time Transport Protocol
(SRTP) Extension for Datagram Transport Layer Security (DTLS)
Reviewer: Joel M. Halpern
Review Date: 28-July-2016
IETF LC End Date: 2016-08-06
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard.

Major issues:

Minor issues:
Is there any way to get clearance from pre-2008 authors to enable 
current copyright text to be used even though old text is copied into 
this document for clarity?


Nits/editorial comments:

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

[Gen-art] Review: draft-pd-dispatch-msrp-websocket-12

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-pd-dispatch-msrp-websocket-12
The WebSocket Protocol as a Transport for the Message Session Relay
Protocol (MSRP)
Reviewer: Joel M. Halpern
Review Date: 16-June-2016
IETF LC End Date: 2016-07-08
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:  N/A

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

[Gen-art] review: draft-ietf-dhc-topo-conf-08

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dhc-topo-conf-08

Reviewer: Joel M. Halpern
Customizing DHCP Configuration on the Basis of Network Topology
Review Date: 13-May-2016
IETF LC End Date: 23-May-2016
IESG Telechat date: N/A

Summary: This document is ready for publication as an Informational RFC.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

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

Re: [Gen-art] review: draft-ietf-bess-multicast-damping-04

[Joel M. Halpern]

Yes, thank you, those edits address my concern quite nicely.
Yours,
Joel

On 5/9/16 4:48 AM, thomas.mo...@orange.com wrote:

Hi Jari, Joel,

2016-05-05, Jari Arkko:

Thanks for your review. Authors, did you note Joel’s suggestion?


Yes, noted and taken into account (hopefully in a satisfying way)
in version -06, uploaded one minute ago.

Best,

-Thomas



On 28 Mar 2016, at 08:08, Joel M. Halpern <j...@joelhalpern.com> wrote:


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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-bess-multicast-damping-04
   Multicast VPN state damping
Reviewer: Joel M. Halpern
Review Date: 28-March-2016
IETF LC End Date: 13-April-2016
IESG Telechat date: N/A

Summary: This document is ready for publication as a proposed standard

Major issues:

Minor issues:

Nits/editorial comments:
   Given that section 6.2 says that this applies to Ethernet VPNs
[RFC7117], it would seem useful to mention this in the introduction.

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





_


Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.



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

Re: [Gen-art] review: draft-sheffer-rfc6982bis-00

[Joel M. Halpern]

I rather like RFC 1369 for its conclusions from the implementation 
experience.

Probably closer to the lines I was thinking of is RFC 5080.

There are many others.
Yours,
Joel

On 4/22/16 5:33 PM, Yaron Sheffer wrote:

Hi Joel,

Thanks for your review!

I would appreciate an example of an existing RFC that documents an
implementation, so we can refer to it in the text.

Best,
 Yaron

On 04/22/2016 09:05 PM, Joel M. Halpern wrote:

Interesting.  I was looking at bullet 4 in section 3, which reads "At
least two [implementations] must be written independently."

Not a big deal.

And yes, I think a sentence or two on other value in implementation
reports would be helpful.  My thought is that there are many cases where
the BCP described here is all that is useful, and some cases where a
longer term record is useful.

Yours,
Joel

On 4/22/16 2:01 PM, Adrian Farrel wrote:

Hi Joel,

Thanks for your time.


  The introduction describes RFC1264 as requiring at least one
implementation.  The general requirement in RFC 1264 is multiple
implementations, at least two independent.  While it is a minor issue,
this document should characterize RFC 1264 more carefully.


I'm not opposed to the change you suggest but I quote from section 4.0
of RFC
1264

|4) One or more implementations must exist.


  In the Alternative Formats section, it strikes me that there
is an
alternative that is sometimes useful that is de-emphasised by the text
as written.  If there has been significant insight gained from the
implementations, that may be useful to capture in a longer-lived
context.  In that case, an RFC describing implementation may still be
useful.  I would appreciate it if the authors would consider adding a
short paragraph to this effect.


Oh, it was certainly not our intention to persuade people not to add
documentation about implementations. I don't think the current text
de-emphasises anything (unless you consider that not talking about
something is
de-emphasis). It would not hurt us to note how implementation reports
have often
been written and how the IESG currently recommends that they are
written.

Cheers,
Adrian





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

Re: [Gen-art] review: draft-sheffer-rfc6982bis-00

[Joel M. Halpern]

Interesting.  I was looking at bullet 4 in section 3, which reads "At 
least two [implementations] must be written independently."


Not a big deal.

And yes, I think a sentence or two on other value in implementation 
reports would be helpful.  My thought is that there are many cases where 
the BCP described here is all that is useful, and some cases where a 
longer term record is useful.


Yours,
Joel

On 4/22/16 2:01 PM, Adrian Farrel wrote:

Hi Joel,

Thanks for your time.


  The introduction describes RFC1264 as requiring at least one
implementation.  The general requirement in RFC 1264 is multiple
implementations, at least two independent.  While it is a minor issue,
this document should characterize RFC 1264 more carefully.


I'm not opposed to the change you suggest but I quote from section 4.0 of RFC
1264

|4) One or more implementations must exist.


  In the Alternative Formats section, it strikes me that there is an
alternative that is sometimes useful that is de-emphasised by the text
as written.  If there has been significant insight gained from the
implementations, that may be useful to capture in a longer-lived
context.  In that case, an RFC describing implementation may still be
useful.  I would appreciate it if the authors would consider adding a
short paragraph to this effect.


Oh, it was certainly not our intention to persuade people not to add
documentation about implementations. I don't think the current text
de-emphasises anything (unless you consider that not talking about something is
de-emphasis). It would not hurt us to note how implementation reports have often
been written and how the IESG currently recommends that they are written.

Cheers,
Adrian



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

[Gen-art] review: draft-sheffer-rfc6982bis-00

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-sheffer-rfc6982bis-00
Improving Awareness of Running Code: The Implementation
Status Section
Reviewer: Joel M. Halpern
Review Date: 22-April-2016
IETF LC End Date: 13-May-2016
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:
The introduction describes RFC1264 as requiring at least one 
implementation.  The general requirement in RFC 1264 is multiple 
implementations, at least two independent.  While it is a minor issue, 
this document should characterize RFC 1264 more carefully.


In the Alternative Formats section, it strikes me that there is an 
alternative that is sometimes useful that is de-emphasised by the text 
as written.  If there has been significant insight gained from the 
implementations, that may be useful to capture in a longer-lived 
context.  In that case, an RFC describing implementation may still be 
useful.  I would appreciate it if the authors would consider adding a 
short paragraph to this effect.


Nits/editorial comments:

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04

[Joel M. Halpern]

Fundamentally, no, it is NOT normalized.  It is the reviewers judgment 
of the importance.


I try to use a measure that says that if I were an AD, I would think 
this was blocking before I mark things as Major.  But that is just me. 
And is still a judgment call.


And, in case it got lost in the shuffle, remember that no gen-art 
comment is blocking unless the IETF Chair decides it is.  Sometimes, he 
takes reviewer majors and makes them no-obj, and sometimes he takes 
reviewer minor and makes them discuss.  He is the one who decides, not 
the reviewer.


Yours,
Joel

On 3/29/16 5:31 PM, Stephen Farrell wrote:


Hi Roni, and gen-art (other cc's dropped)

So, a gen-art question to the gen-art reviewers :-)

What is the criterion for major issue?

I'd not have thought that the issues below (which do deserve
a response) would be such a big deal. I do get that various
collections of IETFers will disagree about such, but I'd hope
that gen-art would/could normalise it's opinion, and if this
is the result, I'm surprised.

Thanks,
S.

On 29/03/16 22:00, Roni Even wrote:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments you
may receive.

Document:  draft-ietf-tls-chacha20-poly1305-04

Reviewer: Roni Even

Review Date:2016-3-28

IETF LC End Date: 2016-4-9

IESG Telechat date:



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







Major issues:

I am wondering why this is a standard track document and not informational
since the registration requirements are specification required.  (RFC5246)



I am also wondering why this document updates RFC5246 and RFC6347



Minor issues:



Nits/editorial comments:








___
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: draft-ietf-bess-multicast-damping-04

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-bess-multicast-damping-04
Multicast VPN state damping
Reviewer: Joel M. Halpern
Review Date: 28-March-2016
IETF LC End Date: 13-April-2016
IESG Telechat date: N/A

Summary: This document is ready for publication as a proposed standard

Major issues:

Minor issues:

Nits/editorial comments:
Given that section 6.2 says that this applies to Ethernet VPNs 
[RFC7117], it would seem useful to mention this in the introduction.


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

Re: [Gen-art] [urn] Review: draft-martin-urn-globus-02

[Joel M. Halpern]

I guess this is between Barry, Jari, and the IESG.

If it were me, it would seem that a document using a new and 
not-yet-approved process would require a normative reference to the new 
process, and could not take effect until the new process was approved.


Yours,
Joel

On 3/17/16 8:50 AM, Barry Leiba wrote:

What I'll say abut this, as responsible AD, is that the
almost-finished urnbis work has updated the registration procedure and
the registration template, and the "Namespace Considerations", along
with the requirement that it "outlines the perceived need for a new
namespace", is no longer there.  That update (see
draft-ietf-urnbis-rfc2141bis-urn, Section 6.4 and Appendix A) is not
yet finished and so isn't official, but the intent is clear and the
last call of this document has been posted to the urnbis working group
for review against the old+new requirements.

My view is that we should not be too rigorous about this point at this stage.

Barry

On Thu, Mar 17, 2016 at 5:15 AM, Jari Arkko <jari.ar...@piuha.net> wrote:

Thanks, Joel.

Authors, any responses to this? I think we need to discuss this…

Jari

On 12 Feb 2016, at 00:26, Joel M. Halpern <j...@joelhalpern.com> wrote:


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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-martin-urn-globus-02
    A URN Namespace for Globus
Reviewer: Joel M. Halpern
Review Date: 11-Feb-2016
IETF LC End Date: 9-March-2016
IESG Telechat date: 17-March-2016

Summary: This document is nearly ready for publication as an informational RFC.

This reviewer assumes that the appropriate message has been or will be sent to 
urn-...@apps.ietf.org.

Major issues:
As per the pointer in this document to RFC 3406 section 4.3, this document is 
required to have a Namespace Considerations section which "outlines the perceived 
need for a new namespace (i.e., where existing namespaces fall short of the proposer's 
requirements)."  While there is a section called Namespace Considerations, what it 
lists is the envisioned usages, not the reasons existing name spaces are insufficient.

Minor issues: N/A

Nits/editorial comments: N/A

___
urn mailing list
u...@ietf.org
https://www.ietf.org/mailman/listinfo/urn






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

[Gen-art] Review: draft-martin-urn-globus-02

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-martin-urn-globus-02
A URN Namespace for Globus
Reviewer: Joel M. Halpern
Review Date: 11-Feb-2016
IETF LC End Date: 9-March-2016
IESG Telechat date: 17-March-2016

Summary: This document is nearly ready for publication as an 
informational RFC.


This reviewer assumes that the appropriate message has been or will be 
sent to urn-...@apps.ietf.org.


Major issues:
As per the pointer in this document to RFC 3406 section 4.3, this 
document is required to have a Namespace Considerations section which 
"outlines the perceived need for a new namespace (i.e., where existing 
namespaces fall short of the proposer's requirements)."  While there is 
a section called Namespace Considerations, what it lists is the 
envisioned usages, not the reasons existing name spaces are insufficient.


Minor issues: N/A

Nits/editorial comments: N/A

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

[Gen-art] Review: draft-ietf-codec-oggopus-10

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-codec-oggopus-10
Ogg Encapsulation for the Opus Audio Codec
Reviewer: Joel M. Halpern
Review Date:
IETF LC End Date: 27-January-2016
IESG Telechat date: N/A

Summary:
This document is nearly ready for publication as a Proposed Standard.
The reviewer believes the status issues needs to be addressed, and 
would like the minor issue identified below discussed.


Major issues:
I do not see how we can have a standards track document for using 
an Informational format.  RFC 3533 is Informational.  At the very least, 
the last call needed to identify the downref to RFC 3533.  (It is not 
clear whether the reference to RFC 4732 needs to be normative or could 
be informative.)


Minor issues:
While I do not completely understand ogg lacing values, there 
appears to be an internal inconsistency in the text in section 3:
1) "if the previous page with packet data does not end in a continued 
packet (i.e., did not end with a lacing value of 255)"
2) "a packet that continues onto a subsequent page (i.e., when the page 
ends with a lacing value of 255)"
The first quote says that continued packets end with a lacing value 
of 255, and the second quote says that continued packets end with a 
lacing value of less than 255.  At the very least, these need to be 
clarified.


Nits/editorial comments:
is there some way to indicate that the ogg encoding constraints 
(e.g. 48kHz granule and 2.5 ms timing) are sufficiently broad to cover 
all needed cases?


Yours,
Joel Halpern

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

Re: [Gen-art] Review: draft-ietf-codec-oggopus-10

[Joel M. Halpern]

That would work very well.  Thanks Tim.
Yours,
Joel

On 1/15/16 6:52 PM, Timothy B. Terriberry wrote:

Joel M. Halpern wrote:

On the minor note, I had not realized those were already relevant
parameters.  Anyone using this can reasonably be expected to know that,
so it is not a big deal.  Given that it would only take one sentence, it
might be nice to add the statement anyway.


We can certainly add text to point out that this is a limitation of RFC
6716, e.g., "The duration of an Opus packet as defined in RFC 6716 can
be any multiple..."

For 48 kHz, we might say, "It is possible to run an Opus decoder at
other sampling rates, but all of them evenly divide 48 kHz. Therefore,
the value in the granule position field always counts samples assuming a
48 kHz decoding rate..."



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

Re: [Gen-art] Review: draft-ietf-codec-oggopus-10

[Joel M. Halpern]

I somehow missed that line (I did go look at the announcement.)  Sorry.

In this case, it seems a bit more extreme than the usual downref.  given 
that it is standardizing the use of this format, it seems to be 
essentially standardizing the document defining the format.


Is the intent of the working group to follow up by moving ogg to 
standards track?


Yours,
Joel

On 1/15/16 10:21 PM, Ben Campbell wrote:

The last call announcement included the following  text:

Please note that the document makes normative references to RFCs 3533
and 4732, which are informational.


Thanks!

Ben.

Sent from my iPhone

On Jan 15, 2016, at 4:26 PM, Joel M. Halpern <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>> wrote:


At the very least, the last call needed to identify the downref to RFC
3533.


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

Re: [Gen-art] Review: draft-ietf-codec-oggopus-10

[Joel M. Halpern]

Thanks Ralph.

On the minor note, I had not realized those were already relevant 
parameters.  Anyone using this can reasonably be expected to know that, 
so it is not a big deal.  Given that it would only take one sentence, it 
might be nice to add the statement anyway.


Yours,
Joel

On 1/15/16 6:41 PM, Ralph Giles wrote:

On 15/01/16 02:26 PM, Joel M. Halpern wrote:

Minor issues:
 While I do not completely understand ogg lacing values, there
appears to be an internal inconsistency in the text in section 3:
1) "if the previous page with packet data does not end in a continued
packet (i.e., did not end with a lacing value of 255)"
2) "a packet that continues onto a subsequent page (i.e., when the page
ends with a lacing value of 255)"
 The first quote says that continued packets end with a lacing value
of 255, and the second quote says that continued packets end with a
lacing value of less than 255.  At the very least, these need to be
clarified.


Thanks for taking time to review the draft. You're right that the logic is 
inverted in the last section. I've corrected the i.e. clause in the last 
paragraph.

 is there some way to indicate that the ogg encoding constraints
(e.g. 48kHz granule and 2.5 ms timing) are sufficiently broad to cover
all needed cases?


Hmm. RFC 6716 sec 2.1.3 and 2.1.4 give 48 kHz and 2.5 ms as the maximum sample 
rate and minumum packet duration, respectively. I suppose sec. 4 of the draft 
assumes these constraints.

It does indicate that 2.5 ms is the minimum packet duration, but we could add a 
reference, or a statement that 48 kHz is the effective maximum sample rate of 
the codec if it's cause for concern.

  -r



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

[Gen-art] Review: draft-ietf-httpbis-legally-restricted-status-04

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-legally-restricted-status-04
An HTTP Status Code to Report Legal Obstacles
Reviewer: Joel M. Halpern
Review Date: 24-November-2015
IETF LC End Date: 4- December-2015
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard

Major issues:

Minor issues:

Nits/editorial comments:
In the introduction, would it be more accurate to say that this is 
for use when the server operator has received and is complying with a 
legal demand ...?


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

[Gen-art] Review: draft-ietf-uta-email-tls-certs-05

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-uta-email-tls-certs-05
Updated TLS Server Identity Check Procedure for Email Related Protocols

Reviewer: Joel M. Halpern
Review Date: 24-November-2015
IETF LC End Date: 4-December-2015
IESG Telechat date: 17-December-2015

Summary: This document is ready for publication as a Proposed Standard.

Major issues:

Minor issues:

Nits/editorial comments:

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

Re: [Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence

[Joel M. Halpern]

Thank you.  This addresses my concern.
Yours,
Joel

On 11/2/15 11:14 PM, Dhruv Dhody wrote:

Hi Julien, All,

So now we have - (and thanks for bearing with me, as we get there...)

IGP Area subobjects in the XRO are local to the current AS.  In case
of multi-AS path computation to exclude an IGP area in a different
AS, IGP Area subobject should be part of Explicit Exclusion Route
Subobject (EXRS) in the IRO to specify the AS in which the IGP area
is to be excluded.  Further policy may be applied to prune/ignore
Area subobjects in XRO after "current AS" change during path
computation.

I have also attached the diff of the working copy to show the GenArt and IANA 
review changes so far.


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

[Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-pce-pcep-domain-sequence
Standard Representation of Domain-Sequence
Reviewer: Joel M. Halpern
Review Date: 29-October-2015
IETF LC End Date: 09-November-2015
IESG Telechat date: N/A

Summary: This draft is almost ready for publication as an experimental RFC.

Major issues:
Given that Exclude Route Objects are not interleaved with include 
Objects, is there a restriction that Area IDs may only be excluded from 
paths within a single AS?


Minor issues:
It seems a bit odd for an Experimental RFC to use "Standard" in its 
title.  As one possible solution, in parallel with the naming of the 
related TEAS draft, this could be "Domain Subobjects for Path 
Computation Engine Protocol."


The procedure for updating AS number scope when observing an IP 
address at a PCE processing an IRO seems fragile as described.  Many of 
the real-time mechanisms for this are error prone.  I would recommend 
that a note be added that this construct be avoided in building IROs 
whenever possible.


Nits/editorial comments:

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

[Gen-art] [Gen-Art] Review: draft-ietf-ace-usecases-07

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ace-usecases-07
ACE use cases
Reviewer: Joel M. Halpern
Review Date: 15-Oct-2015
IETF LC End Date: 22-Oct-2015
IESG Telechat date: 22-Oct-2015

Summary: This document is ready to be published as an Informational RFC.

Major issues: N/A

Minor issues:
I believe ACE should be spelled out in the title.

I am mildly concerned that some of the requirements may be 
undecidable or unmeetable, such as a requirement for easily sanitizing a 
log to leave needed historical information while removing personal 
information (U2.12).  I understand the motivation for this.  But I think 
the document might be helped by a warning about their being conflicting 
goals within or among some requirements.


Nits/editorial comments: N/A

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

Re: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

[Joel M. Halpern]

That would work very well for me.  Thank you for addressing my concerns.
Yours,
Joel

On 10/8/15 10:20 AM, Daniel Migault wrote:

Hi Joel,

Thank you for taking time to review and comment the draft.

We propose to add the following text to clarify the example in section 2 before 
the two last paragraphs. The following text expects to clarify the following 
points:
- 1) The creation of VPN is a local policy matter
- 2) Moving one duplicated VPN to different interfaces may involve multiple 
MOBIKE operations
- 4) There is no needs to create all possible VPNs ( might be similar to 
item 1)

The following text has been added to our local copy. If you would like us to 
publish a new version, feel free to let us know. Our intention is to keep the 
updates local until you ask us to publish the draft.

BR,
Daniel and Valery

NEW TEXT -- BEGIN
Note that it is up to host's local policy which additional VPNs to create and
when to do it. The process of selecting address pairs for migration is
  a local matter. Furthermore, in the case of multiple interfaces on
  both ends care should be taken to avoid the VPNs to be duplicated by both 
ends or moved to the both interfaces.

  In addition multiple MOBIKE operation may be involved from the
  Security Gateway or the VPN End User.
  Suppose, as depicted in Figure 3 for example that the cloned VPN is
  between Interface _0 and Interface_0', and the VPN End User and the
  Security Gateway wants to move it to Interface_1 and Interface_1'. The
  VPN End User may initiate a MOBIKE exchange in order to move it to
  Interface_1, in which case the cloned VPN is now between Interface_1
  and Interface_0'. Then the Security Gateway may also initiate a MOBIKE 
exchange in order to move the VPN to Interface_1' in which case the VPN has 
reached its final destination.
NEW TEXT -- END

-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Friday, October 02, 2015 1:25 PM
To: A. Jean Mahoney; General Area Review Team; 
draft-mglt-ipsecme-clone-ike-sa@ietf.org
Subject: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-mglt-ipsecme-clone-ike-sa-05.txt
Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)

Reviewer: Joel M. Halpern
Review Date: 2-Oct-2015
IETF LC End Date: 27-Oct-2015
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Propsoed Standard 
RFC.

Major issues:
  The introductory material talks about the case where both sides have 
multiple interfaces.  It is not clear what will happen with this mechanism in 
that case.
  In particular, if I have two systems, with three interfaces, it seems 
that this will start by creating the S1-D1 Security Association.
It seems straightforward for each side to create their simple additional 
assocations (S2-D1, S3-D1, and S1-D2, S1-D3).
  But the introduction suggests that we also want to create S2-D2, S3-D3, 
S2-D3, and S3-D2.  With no other guidance, it appears that both sides will try 
to create all four of those, creating 8 security associations instead of 4.
  I hope that I have simply missed something in the document that resolves 
this.

Minor issues:

Nits/editorial comments:



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

[Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-mglt-ipsecme-clone-ike-sa-05.txt
Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)

Reviewer: Joel M. Halpern
Review Date: 2-Oct-2015
IETF LC End Date: 27-Oct-2015
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Propsoed 
Standard RFC.


Major issues:
The introductory material talks about the case where both sides 
have multiple interfaces.  It is not clear what will happen with this 
mechanism in that case.
In particular, if I have two systems, with three interfaces, it 
seems that this will start by creating the S1-D1 Security Association. 
It seems straightforward for each side to create their simple additional 
assocations (S2-D1, S3-D1, and S1-D2, S1-D3).
But the introduction suggests that we also want to create S2-D2, 
S3-D3, S2-D3, and S3-D2.  With no other guidance, it appears that both 
sides will try to create all four of those, creating 8 security 
associations instead of 4.
I hope that I have simply missed something in the document that 
resolves this.


Minor issues:

Nits/editorial comments:

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

Re: [Gen-art] Review: draft-ietf-mpls-lsp-ping-relay-reply-10

[Joel M. Halpern]

Yes, I think adding that would improve readability.

Yours,
Joel

On 9/26/15 9:04 PM, Lizhong Jin wrote:

Hi Joel,
Sorry for the late reply, I missed this email.
Thanks for the second round review. You are right, the stack will grows
downward, but only with the relay nodes, not all nodes along the LSP.
The mechanism is described in section 4.2 paragraph 4.
Do you agree if I add the following:
This stack grows downward, with relay node addresses further along the
LSP appearing lower down in the stack. Please refer to section 4.2 for
the relay node discovery mechanism.

Regards
Lizhong



--

Message: 1
Date: Thu, 17 Sep 2015 21:35:34 -0400
From: "Joel M. Halpern" <j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>
To: "A. Jean Mahoney" <maho...@nostrum.com
<mailto:maho...@nostrum.com>>, General Area Review Team
 <gen-art@ietf.org <mailto:gen-art@ietf.org>>,
"m...@ietf.org <mailto:m...@ietf.org>" <m...@ietf.org
<mailto:m...@ietf.org>>
Subject: [mpls] [Gen-art] Review:
 draft-ietf-mpls-lsp-ping-relay-reply-10
Message-ID: <55fb6a66.5050...@joelhalpern.com
<mailto:55fb6a66.5050...@joelhalpern.com>>
Content-Type: text/plain; charset=windows-1252; format=flowed

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-mpls-lsp-ping-relay-reply-10
  Relayed Echo Reply mechanism for LSP Ping
Reviewer: Joel M. Halpern
Review Date: 17-September-2015
IETF LC End Date: 25-Sept-2015
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard

Major issues: none

Minor issues:
  In this document, the address stack grows downward.  While
reasonable, I think that in the absence of warning of this, readers are
likely to be confused when they read the detailed procedures.  I think
the document would be helped by adding the sentence:
  "This stack grows downward, with addresses further along the LSP
appearing lower down in the stack."
 This could appear right after:
  "-  Stack of Relayed Addresses: a list of relay node addresses."
in section 3.2.

Nits/editorial comments:



--



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

Re: [Gen-art] review: draft-housley-sow-author-statistics-00

[Joel M. Halpern]

Yes, that would address my comments very nicely.
Yours,
Joel

On 9/21/15 6:50 PM, Russ Housley wrote:

Joel:

Does this proposed text address your comments?

Russ

= = = = = = = = =

7.  Thoughts on Future Enhancements

With the planned change in document format, some of the information
obtained through heuristics might be more directly extracted from the
XML file.  Once this format is being used by a significant number of
authors, a future effort might move away from heuristics toward
extraction from the XML file.  To support this approach, it would be
desirable for the new XML schema to make the author's continent of
residence available, even if it not used in the formatting of the
human-readable document.


On Aug 27, 2015, at 5:53 PM, Joel M. Halpern wrote:


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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-housley-sow-author-statistics-00
  Statement of Work for Extensions to the IETF Datatracker for
   Author Statistics
Reviewer: Joel M. Halpern
Review Date: 27-August-2015
IETF LC End Date: 23-September-2015
IESG Telechat date: N/A

Summary: This document is ready for publication as an Informational RFC

Major issues: N/A

Minor issues:
There are a few references in this document to the format evolution.  It 
seems that either this document should provide for additional work as those 
changes occur, or should indicate that such further work will be dealt with 
separately at the appropriate time.

Nits/editorial comments:
I wonder if this document could or should identify additional metadata 
items that the new formats could provide to make these statistics more reliable.





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

[Gen-art] Review: draft-ietf-mpls-lsp-ping-relay-reply-10

[Joel M. Halpern]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-mpls-lsp-ping-relay-reply-10
Relayed Echo Reply mechanism for LSP Ping
Reviewer: Joel M. Halpern
Review Date: 17-September-2015
IETF LC End Date: 25-Sept-2015
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard

Major issues: none

Minor issues:
In this document, the address stack grows downward.  While 
reasonable, I think that in the absence of warning of this, readers are 
likely to be confused when they read the detailed procedures.  I think 
the document would be helped by adding the sentence:
"This stack grows downward, with addresses further along the LSP 
appearing lower down in the stack."

   This could appear right after:
"-  Stack of Relayed Addresses: a list of relay node addresses."
in section 3.2.

Nits/editorial comments:

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

[Gen-art] Review: draft-ietf-lwig-cellular-04

[Joel M. Halpern]

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

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Document: draft-ietf-lwig-cellular-04
Building Power-Efficient CoAP Devices for Cellular Networks
Reviewer: Joel M. Halpern
Review Date: 13-Auguest-2015
IETF LC End Date: 24-August-2015
IESG Telechat date: N/A

Summary: This document is ready for publication as an Informational RFC

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

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

Re: [Gen-art] review: draft-ietf-jose-jwk-thumbprint-05

[Joel M. Halpern]

That would work for me.  It gets in the point that the comparing entity, 
as well as the generating entity, needs to plan for this.


Thank you,
Joel

On 7/6/15 6:29 PM, Mike Jones wrote:

Hi Joel.  Thanks for looking this over again.  Section 3.4 was added
in response to Adam Montville's SecDir comments, in which his focus
was on cases where the hash function didn't have to be known to
multiple parties.  I guess it's only fair that you focus on the cases
where it does. ;-)

Currently the case you're interested in is covered by the last
sentence in 3.4, which reads: Only if multiple parties will be
reproducing the JWK Thumbprint calculation for some reason, will
parties other than the original producer of the JWK Thumbprint need
to know which hash function was used.

I could strength this by making it its own paragraph, saying this:
However, in some cases multiple parties will be reproducing the JWK
Thumbprint calculation and comparing the results.  In these cases,
the parties will need to know which hash function was used and use
the same one.

Would that work for you, or do you have alternative wording to
suggest?

Thanks again, -- Mike

-Original Message- From: Joel Halpern
[mailto:j...@joelhalpern.com] Sent: Monday, July 06, 2015 6:18 AM To:
A. Jean Mahoney; General Area Review Team;
draft-ietf-jose-jwk-thumbprint@tools.ietf.org Subject: Re:
[Gen-art] review: draft-ietf-jose-jwk-thumbprint-05

The document is nearly ready for publication as a Proposed Standard.

Upon  re-review, the addition of section 3.4 raises a question of
clarity.  As written, the text says that the hash function matters
only to the original thumbprint provider.  Should there be a little
bit of text talking about the need for the hash function to be the
same for thumbprints to be comparable, or, phrased alternatively,
that thumbprints with different hashes must not be compared?  If
there were no need for consistent production of the thumbprint, there
would be no need for a Proposed Standard for the document.

Yours, Joel

The new section 3.4 On 6/19/15 12:06 PM, Joel M. Halpern wrote:

I am the assigned Gen-ART reviewer for this draft. For background
on Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call
comments you may receive.

Document: draft-ietf-jose-jwk-thumbprint-05 JSON Web Key (JWK)
Thumbprint Reviewer: Joel M. Halpern Review Date: 19-June-2015 IETF
LC End Date: N/A IESG Telechat date: N/A

Summary: The internet draft is ready for publication as a Proposed
Standard.

[Note to readers: This review is provided because the spreadsheet
said so.  The draft appears not to be in last call yet. Also, this
reviewer did not attempt to second-guess the design choices made by
the WG.  The choices are well-explain, and I understand it to be
the WGs job to make them.]

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

___ 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: draft-ietf-xmpp-posh-04

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-xmpp-posh-04
PKIX over Secure HTTP (POSH)
Reviewer: Joel M. Halpern
Review Date:25-June-2015
IETF LC End Date: 08-July-2015
IESG Telechat date: N/A

Summary: This internet-draft is ready for publication as a Proposed 
Standard RFC.


Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

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

[Gen-art] review: draft-ietf-jose-jwk-thumbprint-05

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-jose-jwk-thumbprint-05
JSON Web Key (JWK) Thumbprint
Reviewer: Joel M. Halpern
Review Date: 19-June-2015
IETF LC End Date: N/A
IESG Telechat date: N/A

Summary: The internet draft is ready for publication as a Proposed Standard.

[Note to readers:
This review is provided because the spreadsheet said so.  The draft 
appears not to be in last call yet.
Also, this reviewer did not attempt to second-guess the design choices 
made by the WG.  The choices are well-explain, and I understand it to be 
the WGs job to make them.]


Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

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

[Gen-art] review: draft-ietf-pcp-proxy-08

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-pcp-proxy-08
Port Control Protocol (PCP) Proxy Function
Reviewer: Joel M. Halpern
Review Date: 19-June-2015
IETF LC End Date: 29-June-2015
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard

Major issues:

Minor issues:

Nits/editorial comments:

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

[Gen-art] Gen-art] Review: draft-ietf-kitten-sasl-oauth-22.txt

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-kitten-sasl-oauth-22.txt
A set of SASL Mechanisms for OAuth
Reviewer: Joel M. Halpern
Review Date: 30-April-2015
IETF LC End Date: 14-May-2015
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

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

[Gen-art] Review: draft-hallambaker-tlsfeature-09

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-hallambaker-tlsfeature-09
X.509v3 TLS Feature Extension
Reviewer: Joel M. Halpern
Review Date: 9-April-2014
IETF LC End Date: 5-May-2014
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard 
RFC (at least to the degree that this non-expert in security can tell.)


Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

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

[Gen-art] review: draft-ietf-scim-use-cases-05

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-scim-use-cases-05
System for Cross-domain Identity Management (SCIM) Definitions,
Overview, and Flows
Reviewer: Joel M. Halpern
Review Date: 30-March-2015
IETF LC End Date: 7-N/A

Summary: This document is ready for publication as an Informational RFC.

Major issues:

Minor issues:

Nits/editorial comments:

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

Re: [Gen-art] Review: draft-klensin-smtp-521code-05.txt

[Joel M. Halpern]

That wording works for me.
Yours,
Joel

On 3/17/15 10:21 AM, John C Klensin wrote:



--On Monday, March 16, 2015 23:06 -0400 Barry Leiba
barryle...@computer.org wrote:


Joel, thanks for the review.


Minor issues:
 The description of the 556 reply code in section 4 seems
 to switch between refering to the generating entity as a
client and as a sesrver.  I presume this is because the
actual sitaution is an SMTP server is trying to pass
information onwards, and in that onwards direction it is a
client which.  But it is still confusing for an SMTP client
to make a determination and then an SMTP server which is
apparently the same entity to generate the rror code to some
other SMPT client.


You're right about why, and you're right that it's confusing.
I think the reader and the text would be better served by
changing the first instance of the word client (in the
second sentence) to server. Even though the server is acting
as a client when it makes the determination that sentence is
talking about, it's acting as a server in the sense that it
will be returning a 556 to the client that it's serving.
Calling it a client here only confuses things.


Hi.  While I agree that the existing text is confusing (although
correct), the suggested fix just substitutes one confusing
arrangement for another, with server used twice in the same
sentence to refer to two different hosts that serve two
different roles.  See if the following rather more complete
rewrite for that second sentence works better:

When an intermediate SMTP system (typically a relay)
that would normally attempt to open a mail connection to
a host referred to in a forward-pointing address can
determine that the host does not accept mail
connections, and do so without attempting to open a
connection to that target host, it is appropriate for it
to return a reply with a 556 code to the system that
sent it the message for outbound transmission.

The eliminates the client and server terminology entirely
and talks instead about actual functions.  I'm tired and there
are probably better ways to stay that, but I think it is an
improvement over both the existing text and the client - server
patch.

There is a case that the above doesn't cover, but neither does
the original paragraph, and that is when a submission server
(sic) encounters a nullMX record or equivalent on initial
lookup.  When the submission server tries to do that, it is
acting as an SMTP client, but the status of messages it returns
to the submitting MUA is deliberately very flexible in the spec
(see Section 3.2 of RFC 6409).

  john




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

[Gen-art] Review: draft-klensin-smtp-521code-05.txt

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-klensin-smtp-521code-05.txt
SMTP 521 and 556 Reply Codes
Reviewer: Joel M. Halpern
Review Date: 12-March-2015
IETF LC End Date: 2-April-2015
IESG Telechat date: 9-April-2015

Summary: This document is ready for publication as a Proposed Standard.

Major issues:

Minor issues:
The description of the 556 reply code in section 4 seems to switch 
between refering to the generating entity as a client and as a sesrver. 
 I presume this is because the actual sitaution is an SMTP server is 
trying to pass information onwards, and in that onwards direction it is 
a client which.  But it is still confusing for an SMTP client to make a 
determination and then an SMTP server which is apparently the same 
entity to generate the rror code to some other SMPT client.


Nits/editorial comments:

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

[Gen-art] review: draft-ietf-kitten-gss-loop-04

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-kitten-gss-loop-04
Structure of the GSS Negotiation Loop
Reviewer: Joel M. Halpern
Review Date: 28-January-2015
IETF LC End Date: 9-February-2015
IESG Telechat date: n/a

Summary: This document is ready for publication as an Informational RFC

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:
Section 3.4 paragraph 2: It is likely appropriate
   for the acceptor to report this error condition to the acceptor via
   the application's communication channel.  I presume that should be
   reported to the initiator?

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

[Gen-art] Review: draft-ietf-opsawg-coman-probstate-reqs-03

[Joel M. Halpern]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-opsawg-coman-probstate-reqs-03
Management of Networks with Constrained Devices: Problem Statement and
  Requirements
Reviewer: Joel M. Halpern
Review Date: 2-January-2014
IETF LC End Date: 14-January-2014
IESG Telechat date: N/A

Summary: This document is ready for publication as an Informational RFC.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:
A loss rate of 10^-0 might be better written as 1.  And sounds 
like a failed link rather than a loss rate, even if the cause is 
interference.  (last paragraph of section 1.3)


Section 3 states that requirements are uniquely identified by three 
digit numbers.  In fact, they are identified by a major section number 
and a three digit minor requirement ID number. (So there is a 1.001 and 
a 2.001).  So the description of the requirements template in the start 
of section 3 should be tuned to match what is being done.


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