Re: [Gen-art] Review of draft-ietf-slim-negotiating-human-language-06

[Randall Gellens]

Hi Dale,

Thank you for your review, I appreciate it.  Please see inline.

At 6:32 PM -0800 2/17/17, Dale Worley wrote:


 Reviewer: Dale Worley
 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-slim-negotiating-human-language-06
 Reviewer:  Dale R. Worley
 Review Date:  2017-02-17
 IETF LC End Date:  2017-02-20
 IESG Telechat date:  [unknown]

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

 * Technical comments

 A. Call failure

 If a call fails due to no available language match, in what way(s)
 does it fail?  Section 5.3 says

If such an offer is received, the receiver MAY
reject the media, ignore the language specified, or attempt to
interpret the intent

 But I suspect it's also allowed for the UAS to fail the call at the
 SIP level.  Whether or not that is allowed (or at least envisioned)
 should be described.  And what response code(s)/warn-code(s) should
 be
 used for that?


The text you quote has been deleted.  The draft does not mandate if 
the call should proceed or fail if there is no language match 
possible, although the draft does provide an optional mechanism to 
indicate the caller's preference that the call not fail, and the 
draft does mention that in the emergency services case, the call will 
likely proceed, but that's a matter of policy not protocol.




 B. Audio/Video coordination

5.2.  New 'humintlang-send' and 'humintlang-recv' attributes

Note that while signed language tags are used with a video stream
 to
indicate sign language, a spoken language tag for a video stream
 in
parallel with an audio stream with the same spoken language tag
indicates a request for a supplemental video stream to see the
speaker.

 And there's a similar paragraph in 5.4:


A spoken language tag for a video stream in conjunction with an

 audio

stream with the same language might indicate a request for
supplemental video to see the speaker.


 I think this mechanism needs to be described more exactly, and in
 particular, it should not depend on the UA understanding which
 language tags are spoken language tags.  It seems to me that a
 workable rule is that there is an audio stream and a video stream and
 they specify exactly the same language tag in their respective
 humintlang attributes.  In that case, it is a request for a spoken
 language with simultaneous video of the speaker, and those requests
 should be considered satisfied only if both streams can be
 established.


The text you quote has been deleted.  A media stream for supplemental 
purposes can be negotiated without a language tag, as normal.




 * The following three items are adjustments to the design which I'd
 like to know have been considered.

 C. "humintlang" seems long to me

 Given the excessive length of SDP in practice, it seems to me that a
 shorter attribute name would be desirable.  E.g., "humlang" as was
 used in some previous versions.  Or is there a coordinated usage with
 other names in the "hum*lang" pattern?


There is no intent for a coordinated pattern.  The name was chosen 
years ago to avoid potential confusion with the 'lang' attribute.  Is 
it worth reopening the issue to potentially save three characters per 
SDP line with a language?




 D. Use the Accept-Language syntax

 It seems to me that it would better to use the Accept-Language syntax
 for the attribute values.  This allows (1) specifiying the quality of
 language experience, allowing clear description of bilingualism, (2)
 a
 unified method of specifying whether or not arbitrary languages are
 acceptable, and (3) abbreviating SDP descriptions.

 In a way, the fact that the current proposal seems to require (but
 does not directly specify) the coordinated absence/presence of an
 asterisk on all of the repetitions of humintlang-send or
 humintlang-recv is a warning that the syntax doesn't represent the
 semantics as well as it might.


The group considered multiple proposals to permit specifying quality, 
preference, q-values, etc. but decided to keep things simple for this 
draft.  There is no intent to require the use of an asterisk (to 
indicate a preference by the caller to not fail the call).  The 
asterisk is a very mild mechanism with no normative effects.  It 
merely conveys the preference of the caller, and is not binding on 
the answerer.



 E. Have an attribute to abbreviate the bidirectionally-symmetric case

 Note that all examples are bidirectionally symmetric, and the text
 says that requests and responses SHOULD be bidirectionally symmetric.
 So it would be a 

Re: [Gen-art] Review of draft-ietf-slim-negotiating-human-language-06

[Randall Gellens]

I am almost done with my reply.  I wasn't ignoring Dale, I've been 
working on his comments.


At 11:28 PM + 2/21/17, Natasha Rooney wrote:

 Hi Dale! Many thanks for these comments, as one of the SLIM chairs 
I'll work on getting some answers to you or I'll request the author 
or one of the SLIM active participants to respond.


 Bernard, Randall and SLIM - see below re Dale's points. 



  A. Call failure 
 Randall or Bernard can you respond to this? I imagine the UA call 
failure method is UA specific, but if there is a clash with SIP 
level call fail then this should be addressed.


  B. Audio/Video coordination 
 I believe the theory behind the current draft is that the spoken 
and video streams will be different in the cases of such things as 
sign language. Video could therefore be sign and audio would be a 
spoken language. I'm not sure if the suggestion he satisfies this 
case?


  C. "humintlang" seems long to me 
 Bernard - I don't see the issue with shortening humintlang, but the 
group might. I suggest we throw this to the group for discussion.


  D. Use the Accept-Language syntax 
 Randall and Bernard - is this an acceptable change? Or one we need 
to discuss further. Seems like a reasonable request, but also a 
larger change, which is why I ask!


  E. Have an attribute to abbreviate the 
bidirectionally-symmetric case 
 I do not remember us having this discussion within the group, 
although it may have occurred before I became chair.
 Randall, Brian or Bernard - has this idea been discussed before? If 
so, can one of you respond with an explanation as to why we haven't 
done this?


  Editorial comments and nits *
 Randall - can you take a look through Dale's editorial comments and 
shout if there is any problems with these suggestions; if 
everything is ok please make the changes.


 Thanks all!

 Natasha Rooney | Internet Engineering Director | Internet and Web 
Team | Technology | GSMA 
| nroo...@gsma.com | +44 (0) 7730 219 765 
| @thisNatasha | Skype: nroo...@gsm.org


 On 18 Feb 2017, at 02:32, Dale Worley 
<wor...@ariadne.com> wrote:


 Reviewer: Dale Worley
 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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 Document:  draft-ietf-slim-negotiating-human-language-06
 Reviewer:  Dale R. Worley
 Review Date:  2017-02-17
 IETF LC End Date:  2017-02-20
 IESG Telechat date:  [unknown]

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

 * Technical comments

 A. Call failure

 If a call fails due to no available language match, in what way(s)
 does it fail?  Section 5.3 says

   If such an offer is received, the receiver MAY
   reject the media, ignore the language specified, or attempt to
   interpret the intent

 But I suspect it's also allowed for the UAS to fail the call at the
 SIP level.  Whether or not that is allowed (or at least envisioned)
 should be described.  And what response code(s)/warn-code(s) should
 be
 used for that?

 B. Audio/Video coordination

   5.2.  New 'humintlang-send' and 'humintlang-recv' attributes

   Note that while signed language tags are used with a video stream
 to
   indicate sign language, a spoken language tag for a video stream
 in
   parallel with an audio stream with the same spoken language tag
   indicates a request for a supplemental video stream to see the
   speaker.

 And there's a similar paragraph in 5.4:


   A spoken language tag for a video stream in conjunction with an


 audio


   stream with the same language might indicate a request for
   supplemental video to see the speaker.



 I think this mechanism needs to be described more exactly, and in
 particular, it should not depend on the UA understanding which
 language tags are spoken language tags.  It seems to me that a
 workable rule is that there is an audio stream and a video stream and
 they specify exactly the same language tag in their respective
 humintlang attributes.  In that case, it is a request for a spoken
 language with simultaneous video of the speaker, and those requests
 should be considered satisfied only if both streams can be
 established.

 * The following three items are adjustments to the design which I'd
 like to know have been considered.

 C. "humintlang" seems long to me

 Given the excessive length of SDP in practice, it seems to me that a
 shorter attribute name would be desirable.  E.g., "humlang" as was
 used in some previous versions.  Or is there a coordinated usage 

Re: [Gen-art] Gen-ART review of draft-ietf-ippm-6man-pdm-option: Server Time

[nalini.elkins]

Jouni,

Here is the thread for your second major comment:

Major comment #2 from you:

>2) The PDM option relation to actual "server" time is somewhat confusing and 
>the 5-tuple does not allow me to detect the real relationship between the 
>>server/application action that caused the generation of the packet and the 
>PDM within the packet. This is specifically an issue with 
>transport/application protocols >that multiplex/interleave multiple 
>application streams into one transport. I have no idea of the actual 
>individual application time since the packets get generated >independent of 
>the processing of a single thread. I would welcome some discussion around 
>here. Section 1.4 last paragraph is going to this direction but is not 
>>sufficient IMHO.

Yes, you are, of course, correct that all traffic will flow between the 
matching ports at the two endpoints. The 5-tuples will match regardless of the 
application.

The thing is that we never intended that PDM would distinguish between 
applications using the same 5-tuple.  That is, it is a feature, not a bug.

What PDM WILL tell you is whether the problem is in the network or the host.    
In our experience, which is primarily on networks for large data centers, there 
is a different group which is involved to troubleshoot the problem depending on 
the nature of the problem.  That is, do I get the application developers on the 
line or the team that deals with the routers & infrastructure.

One of the important functions of PDM is to allow you to do quick triage so 
that you can get the right SWAT team going.   PDM does not tell you if the 
problem is in the IP stack or the application or buffer allocation.   PDM also 
does not tell you which of the network segments or middle boxes is at fault.  
The reason for PDM is to get the right specialists in place who can then be 
dispatched to investigate their area.

In our experience, valuable time is often lost at this first stage of triage.   
Both the network group and the application group have quite a few specialized 
tools at their disposal to further investigate their own areas.

I am adding some of this verbiage to section 1.4.   Please see below:

CURRENT
---

1.4 Rationale for defined solution 

The current IPv6 specification does not provide timing nor a similar 
field in the IPv6 main header or in any extension header. So, we 
define the IPv6 Performance and Diagnostic Metrics destination option 
(PDM). 

Advantages include: 

1. Real measure of actual transactions. 
2. Independence from transport layer protocols. 
3. Ability to span organizational boundaries with consistent 
instrumentation 
4. No time synchronization needed between session partners 
5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) 
in a uniform way 

The PDM provides the ability to determine quickly if the (latency) 
problem is in the network or in the server (application). More 
intermediate measurements may be needed if the host or network 
discrimination is not sufficient. At the client, TCP/IP stack time 
vs. application time may still need to be broken out by client 
software. 


NEW
1.4 Rationale for defined solution 

The current IPv6 specification does not provide timing nor a similar 
field in the IPv6 main header or in any extension header. So, we 
define the IPv6 Performance and Diagnostic Metrics destination option 
(PDM). 

Advantages include: 

1. Real measure of actual transactions. 
2. Independence from transport layer protocols. 
3. Ability to span organizational boundaries with consistent 
instrumentation 
4. No time synchronization needed between session partners 
5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) 
in a uniform way 

The PDM provides the ability to determine quickly if the (latency) 
problem is in the network or in the server (application).  That is,it is a fast 
way to do triage.
One of the important functions of PDM is to allow you to do quickly dispatchthe 
right set of diagnosticians.  Within network or server latency,there may be 
many components.  The job of the diagnostician is to ruleeach one out until the 
culprit is found.
How PDM fits into this diagnostic picture is that PDM will quickly tell you how 
to escalate.  PDM will point to either the network area or theserver area.   
Within the server latency, PDM does not tell you if the bottleneckis in the IP 
stack or the application or buffer allocation. Within the network latency, PDM 
does not tell you which of the network segments or middle boxes is at fault. 
What PDM will tell you is whether the problem is in the network or the server. 
In our experience, there is often a different group which is involved to 
troubleshoot the problem depending on the nature of the problem.   That is, the 
problem may be escalated to the application developersor the team that deals 
with the routers and infrastructure.  Both the network group and the 
application group have quite a few specialized 

[Gen-art] Fw: Gen-ART review of draft-ietf-ippm-6man-pdm-option: Server Time

[nalini.elkins]

I don't know why this email keeps getting cut off!
I am attaching my response in a text file.
Sigh. Thanks,
Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360

 
- Forwarded Message -
 From: "nalini.elk...@insidethestack.com" 
 To: jouni korhonen ; General Area Review Team 
; "draft-ietf-ippm-6man-pdm-option@ietf.org" 
 
Cc: Michael Ackermann ; Robert Hamilton 
; MORTON ALFRED C (AL) 
 Sent: Tuesday, February 21, 2017 10:03 AM
 Subject: Re: Gen-ART review of draft-ietf-ippm-6man-pdm-option: Server Time
   
Resending.  Somehow the last email was cut off. Nalini 
  From: "nalini.elk...@insidethestack.com" 

 To: jouni korhonen ; General Area Review Team 
; "draft-ietf-ippm-6man-pdm-option@ietf.org" 
 
Cc: Michael Ackermann ; Robert Hamilton 
; MORTON ALFRED C (AL) 
 Sent: Tuesday, February 21, 2017 9:59 AM
 Subject: Re: Gen-ART review of draft-ietf-ippm-6man-pdm-option: Server Time
  
Jouni,

Here is the thread for your second major comment:

Major comment #2 from you:

>2) The PDM option relation to actual "server" time is somewhat confusing and 
>the 5-tuple does not allow me to detect the real relationship between the 
>>server/application action that caused the generation of the packet and the 
>PDM within the packet. This is specifically an issue with 
>transport/application protocols >that multiplex/interleave multiple 
>application streams into one transport. I have no idea of the actual 
>individual application time since the packets get generated >independent of 
>the processing of a single thread. I would welcome some discussion around 
>here. Section 1.4 last paragraph is going to this direction but is not 
>>sufficient IMHO.

Yes, you are, of course, correct that all traffic will flow between the 
matching ports at the two endpoints. The 5-tuples will match regardless of the 
application.

The thing is that we never intended that PDM would distinguish between 
applications using the same 5-tuple.  That is, it is a feature, not a bug.

What PDM WILL tell you is whether the problem is in the network or the host.    
In our experience, which is primarily on networks for large data centers, there 
is a different group which is involved to troubleshoot the problem depending on 
the nature of the problem.  That is, do I get the application developers on the 
line or the team that deals with the routers & infrastructure.

One of the important functions of PDM is to allow you to do quick triage so 
that you can get the right SWAT team going.   PDM does not tell you if the 
problem is in the IP stack or the application or buffer allocation.   PDM also 
does not tell you which of the network segments or middle boxes is at fault.  
The reason for PDM is to get the right specialists in place who can then be 
dispatched to investigate their area.

In our experience, valuable time is often lost at this first stage of triage.   
Both the network group and the application group have quite a few specialized 
tools at their disposal to further investigate their own areas.

I am adding some of this verbiage to section 1.4.   Please see below:

CURRENT
---

1.4 Rationale for defined solution 

The current IPv6 specification does not provide timing nor a similar 
field in the IPv6 main header or in any extension header. So, we 
define the IPv6 Performance and Diagnostic Metrics destination option 
(PDM). 

Advantages include: 

1. Real measure of actual transactions. 
2. Independence from transport layer protocols. 
3. Ability to span organizational boundaries with consistent 
instrumentation 
4. No time synchronization needed between session partners 
5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) 
in a uniform way 

The PDM provides the ability to determine quickly if the (latency) 
problem is in the network or in the server (application). More 
intermediate measurements may be needed if the host or network 
discrimination is not sufficient. At the client, TCP/IP stack time 
vs. application time may still need to be broken out by client 
software. 


NEW
1.4 Rationale for defined solution 

The current IPv6 specification does not provide timing nor a similar 
field in the IPv6 main header or in any extension header. So, we 
define the IPv6 Performance and Diagnostic Metrics destination option 
(PDM). 

Advantages include: 

1. Real measure of actual transactions. 
2. Independence from transport layer protocols. 
3. Ability to span organizational boundaries with consistent 
instrumentation 
4. No time synchronization needed between session partners 
5. Ability to handle all transport 

Re: [Gen-art] Gen-ART review of draft-ietf-trill-rfc6439bis-04

[Donald Eastlake]

Hi Christer,

Version -05 of the draft, which was just posted, is intended to resolve
your comments.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

On Thu, Jan 19, 2017 at 7:47 AM, Christer Holmberg <
christer.holmb...@ericsson.com> wrote:

> Hi Donald,
>
> Please see inline.
>
> >> Also, in general, the document does expand some acronyms on first
> >> occurrence, while it does not expand others. Can the authors verify
> >>that all
> >> the acronyms NOT expanded so called ³well known² acronyms?
> >
> >Can you point to one that isn't well known?
>
> I didn¹t check - it was more a generic question whether you have checked
> the non-expanded acronyms.
>
> But, looking in the Introduction:
>
> 1) I see that you have expanded LAN, but not VLAN. Both are well-known, so
> they do not need to be enhanced.
>
> 2) LSP IS a well known acronym, and LSP actually have multiple meanings
> (perhaps they all mean the same thing).
>
> LSP- Label Switched Path (LSP) or
>- Label Switching Path (LSP) -- RARELY USED
>- Link State Packet (LSP) or
>- Link State PDU (LSP) (or Link State Protocol Data Unit)
>
>
> 3) FGL is not a well known acronym.
>
> 4) In the case of DRB you use the following format: 'enhanced (acronym)'.
> In other cases you use 'acronym (enhanced)¹. Please be consistent whenever
> you do write both the acronym and the enhanced name.
>
> Having said that, DRB is a well known acronym, so I don¹t think you need
> to enhance it. Still, as it may be a "less known well known², a reference
> would still be useful.
>
> ...
>
> >> Q4:The end of the introduction contains the following text:
> >>
> >> ³This documents obsoletes [RFC6439], updates [RFC6325], and updates
> >> [RFC7177], as described in Appendix B.²
> >>
> >> That¹s all good, but I think it would be good to have a few words also
> >>in
> >> the Introduction, explaining exactly what is obsoleted and updated.
> >
> >OK, especially as it is more like it incorporates RFC 6439 to simplify
> >things and reduce the number of documents that implementers have to
> >look at.
>
>
> That is also very good information. The details can be in Appendix B, but
> I think it would be good to have a high-level description in the
> Introduction.
>
>
> >> Q5:The end of the introduction contains the following text:
> >>
> >> ³It also includes reference implementation details.
> >>   Alternative implementations that interoperate on the wire
> >>are
> >>   permitted.²
> >>
> >> Is the last sentence really needed? I don¹t think an RFC can mandate the
> >> usage of one specific implementation of the RFC.
> >
> >Well, I think the TRILL WG likes wording similar to that. It also
> >occurs in at least RFC 6325, the TRILL base protocol specification.
>
> Ok. I won¹t argue against it, I just think it sounds a little strange :)
>
> But, could you then add a reference to the section describing the
> reference implementation details, because I don¹t think it is explicit
> anywhere.
>
> Also, if the reference implementation details are different from the ones
> in 6325 I think it would be useful to point out.
>
> Regards,
>
> Christer
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-ietf-ccamp-ospf-availability-extension-09

[Jouni Korhonen]

Reviewer: Jouni Korhonen
Review result: Ready

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

For more information, please see the FAQ at

.

Document: draft-ietf-ccamp-ospf-availability-extension-??
Reviewer: Jouni Korhonen
Review Date: 2017-02-21
IETF LC End Date: 2016-10-24
IESG Telechat date: 2017-03-16

Summary:

I have reviewed two earlier versions of this document. All my comments
have been addressed. I am also happy to see my earlier comments
generated (I believe) a draft addressing the generalized SCSI TLV
specification work in TEAS, and this draft referencing to that work.

Major issues:

none.

Minor issues:

none.

Nits/editorial comments: 

There are minor editorials here and there, but those will be picked up
by the RFC editor in any case.

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

Re: [Gen-art] review of draft-ietf-bmwg-ipv6-nd-04.txt

[Ron Bonica]

Francis,

Thanks for the careful review. Can you suggest a better title?

 Ron

P.S. I have worked the other comments into the next version of the draft.


> -Original Message-
> From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Cerveny, Bill
> Sent: Thursday, February 16, 2017 10:12 AM
> To: Jari Arkko ; Francis Dupont
> 
> Cc: gen-art@ietf.org; draft-ietf-bmwg-ipv6-nd@ietf.org
> Subject: Re: [Gen-art] review of draft-ietf-bmwg-ipv6-nd-04.txt
> 
> Hi Jari
> 
> I’ll review the comments and respond to them.
> 
> Thanks,
> 
> Bill Cerveny
> 
> On 2/16/17, 7:47 AM, "Jari Arkko"  wrote:
> 
> Thanks for the detailed review, Francis!
> 
> Authors — did you make a note of the comments? Did not see a
> response…
> 
> Jari
> 
> On 24 Jan 2017, at 18:33, Francis Dupont 
> 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
> >
> > .
> >
> > Document: draft-ietf-bmwg-ipv6-nd-04.txt
> > Reviewer: Francis Dupont
> > Review Date: 20170116
> > IETF LC End Date: 20170123
> > IESG Telechat date: unknown
> >
> > Summary: Ready with nits
> >
> > Major issues: none
> >
> > Minor issues: the title (and the Abstract) is a bit misleading: it is
> > not the benchmarking of the ND protocol which has ~12 different
> > functions but the benchmarking of a particular function on a router.
> > Now it is the critical one so my concern is more the document is
> > limited to only this one...
> >
> > Nits/editorial comments:
> > - ToC page 2 and 7 page 12: Acknowledgements -> Acknowledgments
> >
> > - 1 page 2: the limit to a router explains why the verb send is
> >  replaced by forward... and why there is nothing about redirection
> >
> > - 1 page 2: determine the IPv6 next-hop's link-layer address
> >  -> determine the outgoing interface and the IPv6 next-hop's
> >   link-layer address
> >
> > - 2.2.1 page 5: et cetera -> etc
> >
> > - 3.1.2 page 9 (twice) and 3.2.2 page 10; recieved -> received
> >
> > - 3.1.2 page 9: IMHO you should define the "initial" term (for final
> >  the meaning is obvious)
> >
> > - 3.2.1 page 10: (i.e.,IPv6 -> (i.e., IPv6
> >
> > - 3.2.2 page 10: in "packets-received will either be
> >   equal to zero or packets-received." the last received -> sent.
> >
> > Regards
> >
> > francis.dup...@fdupont.fr
> >
> > ___
> > 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 mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art