Ben Campbell | 15 Apr 21:28 2014

Re: Gen-ART LC/Telechat Review of draft-ietf-v6ops-64share-09

Hi,

Version 10 addresses all of my comments on version 09.

Thanks!

Ben.

On Apr 1, 2014, at 6:14 PM, Vízdal Aleš <ales.vizdal <at> t-mobile.cz> wrote:

> Dear Ben, all,
>  
> Many thanks for your review. An updated I-D has been submitted.
>  
> Please see inline.
>  
> > -----Original Message-----
> > From: Ben Campbell [mailto:ben <at> nostrum.com]
> > Sent: Friday, March 21, 2014 8:25 PM
> > To: draft-ietf-v6ops-64share.all <at> tools.ietf.org
> > Cc: gen-art <at> ietf.org Team (gen-art <at> ietf.org)
> > Subject: Gen-ART LC/Telechat Review of draft-ietf-v6ops-
> > 64share-09
> >
> > 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 wait for direction from your document shepherd or AD
> > before posting a new version of the draft.
(Continue reading)

Tom Taylor | 13 Apr 23:00 2014
Picon

Gen-ART LC review of draft-ietf-precis-framework-15

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>.

This document is beautifully written and is ready to go. As a person 
unfamiliar with the basic concepts I had to read into the document a bit 
to get traction, then re-read from the beginning, but the additional 
effort was minimal and rewarding.

Document:           draft-ietf-precis-framework-15
Reviewer:           Tom Taylor
Review Date:        13/04/2014
IETF LC End Date:   23/04/2014
IESG Telechat date: 24/04/2014

Summary: This document provides:
-- the historical background leading up to the approach used for
    its technical content
-- definitions of two string classes suitable as bases for two
    general classes of application
-- instructions for creating profiles of the string classes
    (particularly the FreeformClass) for specific applications
-- a satisfying set of security considerations.

This document obsoletes Stringprep (RFC 3454). It establishes new IANA 
registries for derived properties of Unicode code points for Unicode 
versions subsequent to 6.2, for base string classes, and for profiles.

Major issues:
(Continue reading)

A. Jean Mahoney | 10 Apr 23:26 2014

A *new* batch of IETF LC reviews - 2014-04-10

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Suresh Krishnan   2014-04-18   draft-kivinen-ipsecme-ikev2-rfc5996bis-02

Tom Taylor        2014-04-23*  draft-ietf-precis-framework-15

* Since the draft is on the 4/24 telechat, review is actually due 4/22

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

(Continue reading)

R.Jesske | 10 Apr 10:07 2014
Picon

Re: Gen-ART review of draft-drage-sipping-rfc3455bis-13

Hi Marry,

I’m really sorry, this mail slipped through my hands. And I didn’t see anything in the data tracker history. Since I’m the main Editor, it is my fault that this was not answered.

It is true we cannot claim any speed if we do nothing. Again I’m Sorry.

 

So here are my answers. For the Gen-review.

So I have created a Version -14 which I can upload now. Please indicate if I should do this or if I should wait for further comments?

 

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-drage-sipping-rfc3455bis-13

Reviewer: Martin Thomson

Review Date: 2014-02-27

IETF LC End Date: 2014-03-14

IESG Telechat date: (if known)

 

Summary: I find it strange that this 3GPP document is being published on the standards track.  But since it's a -bis there is clearly precedent, and it is otherwise sound.

 

[RJ] Yes it is informal as RFC3455 is I’ll change that.

 

Major issues:

 

This document doesn't include enough information for me to some of the headers.  For example, there isn't enough information in the document to allow me to interpret the contents of cgi-3gpp:

          cgi-3gpp     = "cgi-3gpp" EQUAL (token / quoted-string)

(I pick on P-Access-Network-Info, because I'm somewhat familiar with it.)

 

This can probably be addressed by the inclusion of appropriate normative references.  I seem to recall there being a 3GPP TS that covered at least some of these.

 

[RJ] Below that section we have the text:

The access-info MAY contain additional information relating to the access network. The values for "cgi-3gpp", "utran-cell-id-3gpp",

       "i-wlan-node-id", "dsl-location" and "ci-3gpp2", "ci-3gpp2-femto" and  "gstn-location" are defined in 3GPP TS 24.229

 

Do we need more?

 

Minor issues:

 

RFC 4244 is now obsolete, see 7044.  (related nit: Change log entry #2 seems quite defensive, unnecessarily so.  This document only needs to define P-Called-Party-ID, and reference History-Info as an alternative

mechanism.)

 

[RJ] Replaced

[RJ] Due to your comment I have removed the whole text as follows:

Additionally the P-Called-Party-ID

       header field has been defined within 3GPP systems since release

       5, and therefore it is realistic to expect implementations to be

       already released to the field.  It is therefore considered that

       replacement of the P-Called-Party-ID header field within 3GPP

       systems causes more issues that it solves, and therefore the

       update of RFC3455 <xref

         target="RFC3455"></xref> to remove the P-Called-Party-ID header field

       will not be addressed.  However it is recommended that any new

       usage of this type of functionality should use the History-Info

       header field defined in RFC 7044 <xref target="RFC7044"></xref>rather than the P-Called-Party-ID header field

 

 

Change log entry #5, mentions a shortcoming of 3455 (no registry for access network types), but the draft does nothing about it.  It seems to be propagating the mistake it notes.

 

[RJ] Yes I can agree this. so this seems a action for future.

 

A lot has happened since RFC 3455 was published.  The privacy considerations around the use of P-Access-Network-Info are unchanged from their pre-Geopriv form.  In particular, I find the UA knowledge part to be problematic; Geopriv definitions can probably help here.

 

[RJ] sorry cannot do

 

 

S6.1 P-Associated-URI is a powerful linkability vector, which could be a far more serious privacy leak than the text implies.  The following seems like good advice, but is not sufficient:

 

   An eavesdropper could possibly collect the list of identities a user

   is registered.  This can have privacy implications.  To mitigate this

   problem, this extension SHOULD only be used in a secured environment,

   where encryption of SIP messages is provided either end-to-end or

   hop-by-hop.

 

You also have to trust the other end of the hop with the information.

I think that's implicit, but probably needs to be stated.

 

[RJ] I have addedthe following:

And where a trustrelationship equivalent with that defined in RFC 3325 <xref target="RFC3325">between entities exist

 

 

S6.4  This claim sounds false to me:

 

   However, there

   are no security problems resulting from a UA inserting incorrect

   information.  Networks providing services based on the information

   carried in the P-Access-Network-Info header field will therefore need

   to trust the UA sending the information.  A rogue UA sending false

   access network information will do no more harm than to restrict the

   user from using certain services.

 

Any parameter whereby changing it can cause loss of service is likely to be true in the inverse.  The draft makes no claims that would make me believe otherwise.

 

[RJ] Since we have the P-Access-Network-Info as header that is also set up by the IMS entity P-CSCF with adding the network provided element there is a difference in interpreting the header by Applications. Of course the network provided information is trustful and can be used for sensitive services since the user provided information should only be used by services which are not sensitive.

 

[RJ] Is this sufficient?

 

 

Nits/editorial comments:

 

S1 Having the disclaimer as the first section is a little strange.  I don't know what it is disclaiming yet.

 

[RJ] That is a copy from RFC3455. RFC3455 fullfills the requirements documented in RFC4083. Would this be sufficient to write as a one sentence statement?

 

 

S1, S3 It looks like a few characters are missing from these sections:

"trust.These", "environment The", "[RFC3455]   This"

 

[RJ] Done

 

The change log contains a lot of normative language.  I expected to see pointers to changes, and maybe some justification, but items include normative-sounding text and no pointers(7), other contain pointers and duplicate text (3&4)

 

[RJ] tried to solve this. deleted normative text and made some corrections to your points.

 

Change log #6 notes the removal of a field; given that this is extensible, why not just mark the CDMA 2000 item deprecated instead of removing it?

[RJ] As far as I know is that 3GPP does not want to use it anymore. Is it not sufficent to not the deletion?

 

 

Best Regards

 

Roland

 

Von: Mary Barnes [mailto:mary.ietf.barnes <at> gmail.com]
Gesendet: Donnerstag, 10. April 2014 01:08
An: draft-drage-sipping-rfc3455bis <at> tools.ietf.org
Cc: Atle Monrad; Gonzalo Camarillo; Richard Barnes
Betreff: Fwd: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13

 

Can you guys please respond to Martin's review?  This document is on the IESG telechat agenda for tomorrow.  Honestly, you guys cannot complain that IETF is not doing work in a timely manner if authors cannot respond to reviews like this, especially at this stage of the game. 

 

I will note that I haven't seen all the messages around these reviews because people don't usually add the shepherd and I don't seem to be being picked up by any aliases. 

 

Regards,

Mary. 

---------- Forwarded message ----------
From: Martin Thomson <martin.thomson <at> gmail.com>
Date: Wed, Apr 9, 2014 at 11:39 AM
Subject: Re: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13
To: Jari Arkko <jari.arkko <at> piuha.net>
Cc: "gen-art <at> ietf.org Review Team" <gen-art <at> ietf.org>, IESG IESG <iesg <at> ietf.org>, draft-drage-sipping-rfc3455bis.all <at> tools.ietf.org

On 9 April 2014 05:41, Jari Arkko <jari.arkko <at> piuha.net> wrote:
> Have there been any responses or changes based on your comments? I do not see the document version having changed...

I have seen no response or revision.

 

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Scott Brim | 9 Apr 23:44 2014
Picon

GEN-ART last call review of draft-ietf-ccamp-rsvp-te-eth-oam-ext

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-ccamp-rsvp-te-eth-oam-ext-11
Reviewer: Scott Brim
Review Date: 2014-04-09
IETF LC End Date: 2014-04-15
IESG Telechat date: none yet

Summary: This draft is ready for publication as a Proposed Standard

Major issues: None

Minor issues: None

Nits/editorial comments:

  Nice  job.

  Obsessive copyeditor nit: The sections on sub-TLVs in 3.3 all begin
  with "The ___ Sub-TLV is depicted below, this sub-TLV ...". You should
  end a sentence after "below" and begin a new one with "This".

Scott
Peter Yee | 8 Apr 08:58 2014

Gen-ART LC review of draft-ietf-opsec-lla-only-07

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-opsec-lla-only-07
Reviewer: Peter Yee
Review Date: April-7-2014
IETF LC End Date: April-7-2014
IESG Telechat date: TBD

Summary: This draft is basically ready for publication as an Informational
RFC, but has issues that should be fixed before publication. [Ready with
issues.]

This document discusses the (controversial) use of IPv6 link-local addresses
on router infrastructure links.  I don't find all of the arguments for use
of link-local addresses to be terribly compelling, but I'm not utterly
averse to the document's publication as a summary of some of the pros and
cons for those who desire to configure their routers in the manner
prescribed.  There may be other reasons that should be taken into
consideration, but I lack a network operator's experience to discuss them.

Minor:

Page 4, 4th paragraph: I don't buy this argument.  DNS can be simplified for
non-link-local addresses by simply not registering those addresses in DNS.
Use of link-local addresses isn't a requirement to simplify DNS.

Page 4, 5th paragraph, 2nd sentence: SSH brute force password attacks aren't
really reduced unless the reduction is simply not being able to attack a
single router over multiple interfaces in parallel.  A better scheme for
reducing SSH brute force password attacks might be to limit the rate of
responses to SSH login attempts in the face of repeated failures.
Considering dropping this marginal example.

Page 4, 6th paragraph, 1st sentence: I'm not sure what is meant by "the same
result".  Is this in reference to all 5 paragraphs that precede the 6th?  If
so, you might wish to elaborate with "the same results as the above" .
However, if the same results can be obtained without going to link-local
addressing as this paragraph indicates, why is the use of link-local
addressing being suggested?  The paragraph might do well to explain why one
scheme is preferable over the other.

Page 6, 1st partial paragraph: the argument is made that "more work" is
required to discover all of an IXPs loopback interface addresses before a
generic attack can be mounted.  This wouldn't seem to be a lot of upfront
work and once it has been done, the advantage is negated.  I don't find the
argument particularly persuasive.  

Nits:

Page 2, Section 2 title: change "Address" to "Addressing".

Page 3, second paragraph: change "non link-local" to "non-link-local".

Page 4, 1st paragraph, 3rd sentence: change "accellerated" to "
accelerated".

Page 4, 5th paragraph, 2nd sentence: delete the comma after "[RFC4987])" and
change the "or" to "and".

Page 6, 1st full paragraph, 1st sentence: change "allow" to "allows" and
insert "an" before "MPLS LSP".

		-Peter Yee
Robert Sparks | 7 Apr 21:41 2014

Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11

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-l2vpn-vpls-ldp-mac-opt-11
Reviewer: Robert Sparks
Review Date: 7Apr2014
IETF LC End Date: 8Apr2014
IESG Telechat date: not yet scheduled

Summary: This draft is almost ready for publication as a Proposed 
Standard, but has minor issues (primarily editorial) that should be 
addressed.

I found this document very difficult to read. It asks the reader to hop 
between sections in unusual ways (for instance, it sends the reader to 
the problem statement section for details on normative behavior). I 
strongly encourage an editorial pass focusing on document structure.

There are many instances of SHOULD in the document where the text should 
just be using prose instead. It's not always clear when an 
implementation would choose to ignore the SHOULD, and what the 
consequences of that choice would be.

The document is inconsistent about the level of support needed in the 
network before trying to use this extension.
Section 5.1.2 says the assumption is everything understands it before 
it's turned on. Section 6 points back to figure 2 and says
to use the extension over the pw where you administratively know the 
peer supports the extension, and fall back to 4762 for
everything else. Which of those did you intend?

Specific comments in document order:

Section 3.2 paragraph 1: This paragraph would benefit from being broken 
into several. It's hard to find its point. The SHOULD in this paragraph 
is probably not a 2119 SHOULD (this section isn't defining the 
protocol). It would be useful in this overview to explicitly say _why_ 
"This cannot be achieved with ... 4762]" at this point in the document.

Section 3.2 paragraph 2: This SHOULD _is_ defining protocol - shouldn't 
it be in section 5?

Section 4.1.1 paragraph 3: It took me some time to find Z on the figure. 
It might help to introduce it similar to how you introduce X.

Section 4.1.2: paragraph 1: I think you meant to reference 4.1.1

Section 5: The first sentence talks about requirements in section 4. 
Section 4 describes a problem using some examples but doesn't explicitly 
call out requirements. Doing so would help the document.

Last sentence in 5.1.1 (and several other places in the document): 
Please add an article before "MAC Flush message".  (I apologize for such 
a small nit, but each of these instances made making sure I was reading 
what the sentence intended significantly more difficult).

Section 5.1.2 first paragraph: This section is defining behavior - why 
are you sending the reader back into the problem statement for detail on 
the behavior?

5.1.2 paragraph 2: You meant section 6, not 5.

5.1.2 paragraph 3: I can't follow this paragraph's structure. I think 
you're trying to say "An MTU-s or PE2-rs SHOULD send MAC withdraw 
messages as defined in [RFC4762] in cases where the network is being 
upgraded and devices are not capable of understanding the optimized MAC 
flush." (But if so, the next sentence is redundant.) Why is this SHOULD?

5.1.3 paragraph 1: Why is this a SHOULD and not a MUST? (Similar 
question for the SHOULD in paragraph 2). It's not clear if you're trying 
to avoid "Some things won't implement this spec" or "Don't do this if 
you haven't administratively ensured every element understands this 
extension first" or something else?

5.1.3 paragraph 3: You say "unless specified otherwise". Do you ever 
specify otherwise? Why is this disclaimer here?

5.1.3 last paragraph: You meant section 6 not 5.
Francis Dupont | 7 Apr 14:49 2014
Picon

review of draft-ietf-idr-last-as-reservation-04.txt

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-idr-last-as-reservation-04.txt
Reviewer: Francis Dupont
Review Date: 20140401
IETF LC End Date: 20130403
IESG Telechat date: unknown

Summary: Not Ready

Major issues: there is a typo in the IANA considerations, i.e., the
heart of the document. It seems to be a trivial typo but there is no
proof of this...

Minor issues: None

Nits/editorial comments:
 Appendix A page 4: Acknowledgements -> Acknowledgements

Regards

Francis.Dupont <at> fdupont.fr

PS: the typo looks like a bad cut & paste between versions 03 and 04.
If (/when?) this is confirmed by authors I'll change summary to Ready
and the typo from major issue to editorial.
Elwyn Davies | 4 Apr 20:58 2014
Picon

Gen-art last call review of draft-ietf-mpls-psc-updates-03.txt (review type corrected).

(Sorry...  got the wrong review type in the subject line).

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-mpls-psc-updates-03.txt
Reviewer: Elwyn Davies
Review Date: 4 April 2014
IETF LC End Date: 2014-04-09
IESG Telechat date: (if known) -

Summary:
Almost ready.  

Major Issues:

Minor Issues:
General: 
As discussed during 
Last Call/IETF review of draft-ietf-mpls-tp-psc-itu, RFC 6378 is missing
some details regarding 
- the on-the-wire format of messages
- detection of and behaviour in the event of reception of malformed
messages 
- behaviour in the event of receiving unknown TLV items
- behaviour in the event or receiving unexpected TLV items in a
particular mode.

Specifics:
On-the-wire format: 
- The encoding of the TLV Length field is not specified (unsigned binary
integer in network bit order).
- The encoding of the individual TLV length and Type fields in s2 should
also be specified (unsigned binary integer in network bit order). 
- The value of TLV Length should be more precisely specified.  Suggest:
  The TLV Length is the sum of the lengths of all TLVs in the message, 
  where the length of a TLV is the sum of the lengths of the three
  TLV fields, i.e., the the length of the value field + 4.

Malformed messages check:
- Check values of fields prior to TLV Length are consistent with s4.2 of
RFC 6378.
- Check overall length of message matches value in TLV Length + 12.
- Check Sum of lengths of TLVs matches value in TLV Length. 
- Check all TLV types received are recognized.

Behaviour in the event of receiving a malformed message:
- There has been discussion of appropriate behaviour on the MPLS mailing
list.

Behaviour in the event of receiving a well-formed but inappropriate TLV
in a message:
- This needs to be specified. (might be mode specific)

Nits/Editorial Comments:
General: s/i.e. /i.e., /g, s/e.g. /e.g., /g

Abstract/s1: Make the count of changes consistent (four/five currently).
Might be better just to say 'a number of changes' and leave the reader
to count.

s1: Since the number of items has grown to five and maybe six (depending
on how the above changes are inserted), it would helpful to link the
categorization to the actual section numbers.)

s2: It would be good to have the conventional picture here - just grab
the one from draft-mpls-tp-psc-itu.

s2, Value field: Better to say that this has the number of octets
specified in the length field rather than talking about multiples of 4
again.  The discussion of padding seems superfluous.

s4, next to last para: Should 'A remote No Request message SHALL be ignored' be
'A remote NR message SHALL be ignored' for consistency?

s5,para 8: s/In both cases the request which was driving/In both cases the request that was driving/

s6: It might be worth pointing out that extensions of PSC (like tp-psc-itu) may 
introcuce additional capabilities and state that it is up to these sepcifications to 
say how capability mismatch in this areas is/are handled.

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Elwyn Davies | 4 Apr 20:11 2014

Gen-art telechat review of draft-ietf-mpls-psc-updates-03.txt

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-mpls-psc-updates-03.txt
Reviewer: Elwyn Davies
Review Date: 4 April 2014
IETF LC End Date: 2014-04-09
IESG Telechat date: (if known) -

Summary:
Almost ready.  

Major Issues:

Minor Issues:
General: 
As discussed during 
Last Call/IETF review of draft-ietf-mpls-tp-psc-itu, RFC 6378 is missing
some details regarding 
- the on-the-wire format of messages
- detection of and behaviour in the event of reception of malformed
messages 
- behaviour in the event of receiving unknown TLV items
- behaviour in the event or receiving unexpected TLV items in a
particular mode.

Specifics:
On-the-wire format: 
- The encoding of the TLV Length field is not specified (unsigned binary
integer in network bit order).
- The encoding of the individual TLV length and Type fields in s2 should
also be specified (unsigned binary integer in network bit order). 
- The value of TLV Length should be more precisely specified.  Suggest:
  The TLV Length is the sum of the lengths of all TLVs in the message, 
  where the length of a TLV is the sum of the lengths of the three
  TLV fields, i.e., the the length of the value field + 4.

Malformed messages check:
- Check values of fields prior to TLV Length are consistent with s4.2 of
RFC 6378.
- Check overall length of message matches value in TLV Length + 12.
- Check Sum of lengths of TLVs matches value in TLV Length. 
- Check all TLV types received are recognized.

Behaviour in the event of receiving a malformed message:
- There has been discussion of appropriate behaviour on the MPLS mailing
list.

Behaviour in the event of receiving a well-formed but inappropriate TLV
in a message:
- This needs to be specified. (might be mode specific)

Nits/Editorial Comments:
General: s/i.e. /i.e., /g, s/e.g. /e.g., /g

Abstract/s1: Make the count of changes consistent (four/five currently).
Might be better just to say 'a number of changes' and leave the reader
to count.

s1: Since the number of items has grown to five and maybe six (depending
on how the above changes are inserted), it would helpful to link the
categorization to the actual section numbers.)

s2: It would be good to have the conventional picture here - just grab
the one from draft-mpls-tp-psc-itu.

s2, Value field: Better to say that this has the number of octets
specified in the length field rather than talking about multiples of 4
again.  The discussion of padding seems superfluous.

s4, next to last para: Should 'A remote No Request message SHALL be ignored' be
'A remote NR message SHALL be ignored' for consistency?

s5,para 8: s/In both cases the request which was driving/In both cases the request that was driving/

s6: It might be worth pointing out that extensions of PSC (like tp-psc-itu) may 
introcuce additional capabilities and state that it is up to these sepcifications to 
say how capability mismatch in this areas is/are handled.
Meral Shirazipour | 4 Apr 19:43 2014
Picon

Gen-ART Telechat Call review of draft-ietf-xrblock-rtcp-xr-loss-conceal-11

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 wait for direction from your document shepherd or AD before posting a new version of the draft.

 

Document: draft-ietf-xrblock-rtcp-xr-loss-conceal-11

Reviewer: Meral Shirazipour

Review Date: 2014-04-04

IETF LC End Date: 2013-03-28

IESG Telechat date: 2014-04-10

 

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

 

 

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson Research

www.ericsson.com

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Gmane