Posibles anulaciones
-
- Usuario registrado
- Mensajes: 134
- Registrado: 23 May 2017, 11:57
- Agradecido: 0
- Agradecimiento recibido: 0
Re: Posibles anulaciones
Especifico en TAI, ya que el título no dice la oposición a la que te refieres.
La 34:
Meego es Tizen ahora. Y ubuntu(touch, con el "apellido" que quieras sigue siendo ubuntu) si que es para móvil, es más que impugnable. Serían válidas las 2????![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
La 34:
Meego es Tizen ahora. Y ubuntu(touch, con el "apellido" que quieras sigue siendo ubuntu) si que es para móvil, es más que impugnable. Serían válidas las 2????
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
-
- Usuario registrado
- Mensajes: 17
- Registrado: 31 Ene 2018, 09:45
- Agradecido: 0
- Agradecimiento recibido: 0
Re: Posibles anulaciones
Yo tampoco estoy de acuerdo con la 85 de TAI...cual piensas que es la respuesta correcta??
-
- Usuario registrado
- Mensajes: 34
- Registrado: 27 Feb 2017, 17:57
- Agradecido: 0
- Agradecimiento recibido: 0
Re: Posibles anulaciones
Marque la opción c) como la correcta. En la web del Centro Criptológico Nacional tienes muchas fuentes que indican que la definición de "Vulnerabilidad" no se corresponde con la que aparece en la opción c) y por lo tanto esa opción sería incorrecta.victoriaPlum escribió: ↑22 May 2018, 20:22Yo tampoco estoy de acuerdo con la 85 de TAI...cual piensas que es la respuesta correcta??
-
- Usuario registrado
- Mensajes: 17
- Registrado: 31 Ene 2018, 09:45
- Agradecido: 0
- Agradecimiento recibido: 0
Re: Posibles anulaciones
Pues estamos de acuerdo, yo también marqué la respuesta C, así que me apunto a impugnarla también.
-
- Usuario registrado
- Mensajes: 20
- Registrado: 17 Ene 2015, 18:22
- Agradecido: 1 vez
- Agradecimiento recibido: 0
-
- Usuario registrado
- Mensajes: 16
- Registrado: 05 Mar 2017, 15:14
- Agradecido: 0
- Agradecimiento recibido: 0
Re: Posibles anulaciones
En A2, la pregunta 81, a mi no me queda clara, ¿ se podria impugnar ?.
modos de asignacion permitidos en DHCP, entiendo que asignacion manual es lo mismo que asignacion estatica. alguien puede aclararmela.???
En wikipedia hace referencia a manual y estatica al mismo concepto. Entiendo entonces que hay 4 respuestas buenas en la pregunta.
https://en.wikipedia.org/wiki/Dynamic_H ... n_Protocol
modos de asignacion permitidos en DHCP, entiendo que asignacion manual es lo mismo que asignacion estatica. alguien puede aclararmela.???
En wikipedia hace referencia a manual y estatica al mismo concepto. Entiendo entonces que hay 4 respuestas buenas en la pregunta.
https://en.wikipedia.org/wiki/Dynamic_H ... n_Protocol
-
- Usuario registrado
- Mensajes: 20
- Registrado: 17 Ene 2015, 18:22
- Agradecido: 1 vez
- Agradecimiento recibido: 0
Re: Posibles anulaciones
Hola Mon35
respecto a lo que comentas de DHCP, esa pregunta no es impugnable.
De la RFC 1541:
DHCP supports three mechanisms for IP address allocation. In
"automatic allocation", DHCP assigns a permanent IP address to a
host. In "dynamic allocation", DHCP assigns an IP address to a host
for a limited period of time (or until the host explicitly
relinquishes the address). In "manual allocation", a host's IP
address is assigned by the network administrator, and DHCP is used
simply to convey the assigned address to the host.
respecto a lo que comentas de DHCP, esa pregunta no es impugnable.
De la RFC 1541:
DHCP supports three mechanisms for IP address allocation. In
"automatic allocation", DHCP assigns a permanent IP address to a
host. In "dynamic allocation", DHCP assigns an IP address to a host
for a limited period of time (or until the host explicitly
relinquishes the address). In "manual allocation", a host's IP
address is assigned by the network administrator, and DHCP is used
simply to convey the assigned address to the host.
-
- Usuario registrado
- Mensajes: 16
- Registrado: 05 Mar 2017, 15:14
- Agradecido: 0
- Agradecimiento recibido: 0
Re: Posibles anulaciones
El protocolo si admite una asignacion estatica a traves de la asignacion manual, en la pregunta no especifican el RFC, por lo tanto es ambigua desde mi punto de vista. Si hubieran preguntado segun el RFC que tipos de asignaciones estan permitidos, entenderia que en ese caso es como dices tu, mi duda viene porque no especifican el RFC, por lo tanto asignacion estatica y manual vienen a ser lo mismo.
- Rob
- Usuario registrado
- Mensajes: 29
- Registrado: 11 Feb 2007, 11:05
- Agradecido: 0
- Agradecimiento recibido: 0
Re: Posibles anulaciones
Buenos días,
respecto de la pregunta 85 - TAI (Libre), yo también la he impugnado porque la definición de "Vulnerabilidad" que se aporta es muy vaga e imprecisa y no se parece en absoluto a la que ofrecen las fuentes legislativas que teníamos que estudiar (RD3/2010 - ENS) o los organismos de referencia (guías del INCIBE y del CCN-CERT), que además coinciden entre sí unánimemente en describirlo como una "debilidad" [de un activo].
Esto es lo que dan por bueno en el examen:
Saludos.
respecto de la pregunta 85 - TAI (Libre), yo también la he impugnado porque la definición de "Vulnerabilidad" que se aporta es muy vaga e imprecisa y no se parece en absoluto a la que ofrecen las fuentes legislativas que teníamos que estudiar (RD3/2010 - ENS) o los organismos de referencia (guías del INCIBE y del CCN-CERT), que además coinciden entre sí unánimemente en describirlo como una "debilidad" [de un activo].
Esto es lo que dan por bueno en el examen:
Y esto lo que dicen las fuentes que comento arriba:c) Vulnerabilidad: posibilidad de ocurrencia, es decir, de materialización de una amenaza sobre un activo.
- RD3/2010, ENS (Anexo IV. Glosario): “Una debilidad que puede ser aprovechada por una amenaza”
- Incibe: Guía de Gestión de Riesgos (Pág 5.Conceptos) :“Debilidad que presentan los activos y que facilita la materialización de las amenazas.”
- CCN-CERT: Guías Generales (Abreviaturas): “Debilidad de un activo o de un control que puede ser explotada por una o más amenazas.”
Saludos.
-
- Usuario registrado
- Mensajes: 24
- Registrado: 07 May 2013, 17:41
- Agradecido: 0
- Agradecimiento recibido: 0
Re: Posibles anulaciones
Hola,
¿Qué opináis de la pregunta del A2 nº 49? Creo que es una pregunta anulable por estar actualmente activo un estándar por parte del ieee que hace exactamente lo mismo y estar el 830 ya sustituido por éste => https://ieeexplore.ieee.org/document/6146379/versions
Si os metéis, el estándar 830 (revisión del 1998) aparece como Superseded, es decir, superada, y sustituida por el estándar ISO/IEC/IEEE 29148:2011(E) - Requirements engineering.
En un principio, por lo que he podido leer en el estándar nuevo, los requisitos recogidos en el estándar 29148:2011, en el apartado del documento del ieee "A.2.3.3 Description of the current system or situation", son: i) Quality attributes, such as: availability, correctness, efficiency, expandability, flexibility, interoperability, maintain-ability, portability, reliability, reusability, supportability, survivability, and usability
Que se traducen a: disponibilidad, corrección, eficiencia, extensibilidad, flexibilidad, interoperabilidad, mantenibilidad, portabilidad, fiabilidad, reusabilidad, soportabilidad y sostenibilidad/supervivencia.
Es decir, la respuesta b), es correcta, pero es correcta para un estándar desfasado.
Un saludo,
¿Qué opináis de la pregunta del A2 nº 49? Creo que es una pregunta anulable por estar actualmente activo un estándar por parte del ieee que hace exactamente lo mismo y estar el 830 ya sustituido por éste => https://ieeexplore.ieee.org/document/6146379/versions
Si os metéis, el estándar 830 (revisión del 1998) aparece como Superseded, es decir, superada, y sustituida por el estándar ISO/IEC/IEEE 29148:2011(E) - Requirements engineering.
En un principio, por lo que he podido leer en el estándar nuevo, los requisitos recogidos en el estándar 29148:2011, en el apartado del documento del ieee "A.2.3.3 Description of the current system or situation", son: i) Quality attributes, such as: availability, correctness, efficiency, expandability, flexibility, interoperability, maintain-ability, portability, reliability, reusability, supportability, survivability, and usability
Que se traducen a: disponibilidad, corrección, eficiencia, extensibilidad, flexibilidad, interoperabilidad, mantenibilidad, portabilidad, fiabilidad, reusabilidad, soportabilidad y sostenibilidad/supervivencia.
Es decir, la respuesta b), es correcta, pero es correcta para un estándar desfasado.
Un saludo,
-
- Usuario registrado
- Mensajes: 20
- Registrado: 17 Ene 2015, 18:22
- Agradecido: 1 vez
- Agradecimiento recibido: 0
Re: Posibles anulaciones
Hola Mon35,
a mi me vendría bien que se impugnara.
Lo que te he puesto, es lo que pone literal en la RFC, no lo digo yo.
Yo creo que no es impugnable porque como hay que fundamentar la impugnación, no creo que Wikipedia sea suficiente.
Saludos,
a mi me vendría bien que se impugnara.
Lo que te he puesto, es lo que pone literal en la RFC, no lo digo yo.
Yo creo que no es impugnable porque como hay que fundamentar la impugnación, no creo que Wikipedia sea suficiente.
Saludos,